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INTRODUCTION 

Considering the major strides that hove been made in 
twenty-five years in computer science and more specifically 
In software design, the techniques available for developing 
large reliable systems or even producing correct medium-sized 
programs are disappoint ins. We r.enerally attack a problem by 
choosing some programming language and then proceed to design 
the program using an iterative process of coding 3nd 
debugging. Unfortunately after completing these steps of 
program preparation, we still have no guarantee that our 
product is error-free. Instead a general method for 
developing programs which are assured to be correct is 
needed. This field of research cones under the heading of 
re1 table pror.rammin . fl . 

Reliable programming can be defined into two general 
categories. The first is the "analytical" approach 
encouraged by Floyd(l), Ulng<2), LondonO), and others who 
attempt to prove a program correct after it has been written. 
This is accomplished by deriving assertions about values of 
variables and control patterns within the program. From 
these assertions, one then uses mathematical methods in 
trying to deduce the desired end result of the program. 

The second approach, called "constructive" and primarily 
Introduced by P i j ks traU) , is to develop a method for 
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con st rue ting correct programs rather than proving the 
reliability of previously written programs. The goal of the 
constructive approach is writing programs that are easier to 
prove correct. This is accomplished by adhering to 

established programming restrictions while writing a program 
which, in turn, causes the program to be constructed as a 
hierarchy of layers. Guaranteeing the reliability of the 
program is then reduced to proving the correctness of each 
layer. The hope is that larger programs can be handled by 
the analytic approach. 

The general constructive rethod that has been developed 
is structures programming (other nanes used are programming 
by levels of abstraction and programming by stepwise 
refinement). Mthough Uijkstra pioneered most of the early 
research in this area, several other papers have now followed 
including those written by Wlrth(5), Parnas(G), Henderson and 
Snowdon(7), Woodger (8 ), NaurO), and Llskov(lO). Their works 
have all pointed out that what is really needed is a more 
systematic way to go about programming--a systematic 
programming method that leads to clear, readable, provable, 
and thus reliable programs. 

Structured Programing 

Structured programming Is >i design tool for building 
programs in u "top down" fashion by means of a process of 
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successivc decomposition. When we soy "too down 11 v.o inean the 

ability to Introduce and use objects while designing a 

program before the objects are necessarily defined. On the 

other hand/ a "bottom up" approach--requ I red in most 

present-day programming 1 anr,ua&es"-means that on object must 

be defined in the language before it can be used. The first 

step in structured programming is to write a program which 

solves the given problem. However, In general this Initial 

program Is not In a form understandable by the machine on 

which we arc programming but instead only on some abstract 

machine. This abstract machine provides us with just those 

data, ob iects arn\ ooerat ions which have been generated by our 

program and are therefore suitable for solving the problem. 

This program is referred to as our top level abstraction. As 

was earlier noted, the fact is that names of operations and 

data structures may not be recognizable by the actual 

machine; so we refine these names by using real machine 

constructs as well as lower level abstractions which 

themselves, In turn, must be subsequently developed until our 

program Is completely understandable by the machine on which 

the program is to be run. 

Problem Overview 

Most higher level languages today give the programmer 
the ability to design abstract operations through the usage 
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of procedural mechanisms. However, there seems to be no 
analogous method for handling abstract data objects. 
Obviously, if we hope to design programs by means of a 
structured approach, this second requirement is as necessary 
as the first. 

Currently at the Massachusetts Institute of Technology 
research is being directed towards the development of a new 
programming language to be used specifically in conjunction 
with the structured programming mcthodology( 11) . While it is 
being assumed that current langugaes do not have suitable 
mechanisms for constructing data objects, it is not obvious 
that this opinion is justified. in an attempt to remedy this 
predicament, we will begin by analyzing the concept of data 
abstractions and how one would program them in some present 
Jay languages. Although our choice of languages becomes 
relevant to our successes and failures, it is important to 
recognize that we have chosen languages which have been all 
designed with different concepts in mind. The languages 
chosen are 1)PL/ I --described by IBM as an "all-purpose 
language", 2)I'ascal--a language with numerous data 
structuring facilities, 3)£Ll--an extensible language, and 
U)$lllULA(J7--a s imul at ion 1 anguai.e. 

We do not intend to evaluate these languages in terms of 
the goals of their designers; instead these languages will be 
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judged by how well they meet our design criteria set forth by 
structured programming . We will pay particular emphasis on 
their abilities to represent data abstractions. As a result 
of the insights gained by this study, we will expect to 
answer the question of whether or not another programming 
language must be developed for structured programming. 
Furthermore, if there is a need for a new language of this 
type, what we have learned from this analysis should prove 
useful . 

He fore we explore these languages, we present a more 
detailed history of the problems of structured programming so 
that the roadcr will feel more competent when judging and 
trying to resolve the pros and cons of each language. 
Criteria upon which these assesments will be made will also 
be presented shortly. 
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HISTORY 

Program reliability from the- analytical point of view 
has encouraged much research from the latter part of the 
1960's up till the present. These years of effort have 
produced much material on the subject ranging from improved 
resolution schemes for logfc(12) to assert ion- type 
languages( 13 ) . However, one fact becomes fairly obvious: the 
more unstructured-- i n the sense of wild control flow and 
enormous (tut unecessary) size--a program is, the more 
difficult the problem of deriving assertions in order to 
prove the program correct. Furthermore, the increase in 
difficulty seems to be more on the order of exponential (and 
approaching impossible) than linear. Indeed, it seems Chat 
if only some straightforward design methodology for 
programming were adhered to during the development of the 
program, that finding these assertions would be much easier. 

This has been one or the goals of the constructive 
approach and in particular structured programming. As we 
noted earlier (but explain now in fuller detail), by building 
a program in th 1 s fashion, we produce an arrangement of 
layers, corresponding to levels of abstraction, each with 
only one entry and one exit. The reliability of the program 
is based upon the reliability of each succeeding layer, and a 
change made to some higher level of abstraction (that is, an 
earlier conceived level) has no effect on the reliability of 
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lower levels. Thus proving the correctness of the entire 
program is reduced to proving the correctness of each layer 
in an orderly fashion. The correctness of each layer is not 
too difficult to prove as a result of making the following 
restriction: control sequencing is limited to the 
concatenation of assignment, I F-THEU-ELSE, DO WHILE, and 
possibly CASH statements; the correctness of each layer 
relies upon the fact that these statements correspond to 
proofs using mathematical met nous of enumeration, case 
analysis, and induction. 

An EAflMlLii 

At this point an example is presented to help clarify 
the method followed in structured programming and its 
associated reliability characteristics. Written In a 
PL/l-like language* the example will also display English 
phrases and undefined symbols at one level that must be 
refined at lower levels. Suppose the problem is to write a 
compiler for PL/I. Then the top level would be: 

I Write o compiler for PL/ 1 programs; 

Now if we had a machine capable of understanding level I, 
then we would have no need to proceed further; however, we 
v/l 1 1 assume this not to be the case. 

Instead wc will refine the above program thus obtaining: 
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t I program: 

DUCLAKE sourcejjrosram CHARACTER VARYING; 
source__program ■ I [I PUT; 
trans) ate ( source_procram) ; 



Level II consists of naming the variable source_pro£ram, 
which is to be type varying length character -.equence/ and 
two actions, INPUT and "translate". The assumption we will 
make here is that the machine understands DECLARE, CHARACTER, 
VARYING, and INPUT but not "translate". Assuming that lilPUT 
sets the source^prosram to the program to be compiled and 
"translate" does indeed produce the correct object code, it 
is easy to sec that level II solves the problem. The 
reliability of level II must be partially intuitive since the 
specifications of the action "translate" are not defined. 
Tliis particular point concerning reliability should be well 
understood and Is therefore reiterated here: at level II it 

is unnecessary to know how "translate" works but only what it 

is supposed to do; furthermore since we have no semantics to 
express what the function of "translate" is, our proof relies 

partly on enumeration (concatenation of statements) and 

partly on intuition. 

The next refinement is a result of our actual machine 
not understand i nr, the action translate. 
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I I I translate(x); 

DECLARE x CHARACTER VARYING; 
DECLARE phrasc_s t ructure tree; 
phrase_st ructure = recount ze(x ); 
genera te_code(phrasc_st ructure); 

Level III introduces the parameter x, variable 

phrase_structure of type tree, and operations recognize and 
generate. Of these, only x is completely understood by the 
machine on which we will eventually run and the problem of 
what to refine next must be resolved. (The question of what 
to refine next has no simple sol ut ion--see discussion in 
fol 1 owi ng sect ion , ) 

At this point I will stop because I feel the reader 
should have a reasonable understanding concerning the 
development of the compiler program. He should also lie able 
to convince himself that ir all the data types and operations 
introduced so for were recognizable by our machine, not only 
would the program be complete but it would also be correct. 
As was the case for level II, the way by which one can show 
the reliability for level III results from programming In a 
structured manner. For instance, to prove the reliability of 
level IN, one needs to show nothing of the details 

concerning the operations recognize and generate ami the data 
structure tree hut only what the two actions are supposed to 
do and that the representation of the data structure tree 
will be refined at some lower level. 
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As was earlier recognized, refinement of action such as 
"translate" in the compiler example can l>e expressed by the 
combination of procedure-like structures and a good library 
system which supports linking of action names with action 
definitions. This would allow the programmer the advantage 
of be inn able to build the program in a top-down fashion. 
Indeed, the development of a language which provides the 
structured logic and library system to back up the compiler 
would provide a solid foundation for the development of a 
language specifically designed for structured programming. 

On the other hand, the method In which data 
specifications in structured programming should be handled Is 
unclear. for instance, in the compiler example how do we 
represent the abstraction "tree" and any associated operators 
(eg. we may wish to include the actions traverse, add_a_node, 
and delcte_a_node operating on trees)? This Issue is closely 
bound to the first problem of when and how one should define 
and refine data structures. Certainly the representation of 
the data structure will have a profound effect on the 
efficiency of t he program and the ease of writing the 
functions which will operate on the data. But how is the 
programmer to decide upon the details of the structure while 
still conforming to a top-down development of the program7 

The more generally held belief Is to defer those 
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doclslons concerning the details of data representation as 
long as possible which hopefully leads to refinement of 
program and data specifications in parallel. The following 
example will help the reader become more familiar with the 
questions of data format that the programmer must face In 
structured programmi ng . 

WIrth(5) develops a program to solve the 8-queens 
problem by a "successive decomposition or refinement of 
spec! f ica tlon. . . (unt I 1 ) all Instructions are expressed in 
terms of an underlying computer or programming language." 
The 8-queens problem Is described as follows: given an 8x8 
chessboard and 8 queens, find a position for each queen so 
that no queen can take another (i.e. such that every row, 
column, and diagonal contains at most one queen). The first 
data decision that WIrth must make Is when to define the 
board, he decides upon a time when it actually becomes 
necessary to access and manipulate parts of the board. 

Then the decision of how to represent the board becomes 
of primary Importance. An obvious solution consists of 
Introducing a boolean matrix B(l:8,l:8) such that I3(i,j) ° 
true denotes that square (i,j) is occupied. But instead 
Uirth chooses the representation: 



■n tore r j (0<»j<=9) 

' P.t££e.L array x(l:8) (OOxi < = 8) 
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such that j is the index of the currently inspected column 
(allowing j to equal 9 will indicate that the solution is 
found), (xj,j) is the coordinate of the last inspected 
square, and the position of the queen in column k Is given by 
the coordinate pair (xk,k) on the board. In justifying this 
decision, WIrth says "It Is fairly evident even at this stage 
that the. . .(second) choice is more suitable than a boolean 
matrix in terms of simplicity of later instructions as well 
as of storage economy." 

So it seems that although structured programming Is a 
top-down process, a bottom-up justification has been given to 
support n choice of data representations. Unfortunately, if 
It Is discovered that a wrong choice has been made, one will 
be forced to back up. An analysis of the trade-off between a 
strict top-down development and necessary backup might 
Improve any decision policy on what to refine next and what 
format the refinement should take. 

In principle there seem to be two ways of answering the 
first question of when to refine data. Wo can do it as soon 
as we realize that a particular data structure is needed some 
time In the program or we can postpone the definition until 
tfiat data structure must be defined In order for us to bo 
able to continue along our path of refinement. 
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So now the problem becomes one of trying to formulate 
some rules or tactics concerning the refinement of data. 
Ideally, they would ensure the programmer of being able t 
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turn, we may then have hopes of being successful in solving 
the first problem of when and how to refine data. Before 
Investigating different languages, let us explore precisely 
what criteria need be satisfied by a language acceptable for 
expressing abstract data and what examples we may wish to use 
In evaluating the different languages. 



PROGRAMMING LANGUAGE CRITERIA FOR HATA ABSTRACTIONS 

We noted earlier that as a result of using structured 
programming techniques/ both abstract data objects and 
ahstract operators are generated. These objects will 
henceforth be referred to as data abstractions and operator 
abstractions respectively. We have also established the fact 
that operator abstractions can be fairly well represented by 
procedure-like mechanisms common to most present-day 
programming languages. So It Is at this point that we are 
most Interested In establishing criteria for representation 
of e data abstraction the must be met by a programming 
language . 

Some of the lesser data structuring requirements will 
become clear as we analyze the languages with the aim of 
producing programs through the use of structured programming. 
However, the major criteria should be made very precise at 
this point In the paper so that we have both set goals around 
which programs should be designed In our given language and a 
model for comparison of programs. 

One obvious and possibly the most Important requirement 
Is that of being able to express data abstractions within the 
confines of the language. More explicitly, our view Is that 
the data abstraction Introduces some abstract data type, and 
variables of this type may only assume values corresponding 
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to this type (just as in ALGOL60, say, variables of type real 
may only assume values that are real numbers). Thp abstract 
data type Is explicitly defined by some sot of operations 
which may operate on variables declared of that type. The 
Implementation of the abstraction may then bo viewed as a 
form consisting of two parts: Dthe underlying 

representation of the abstract data type and 2)the actions 
defined to operate on variables of that data type by 
manipulating Its underlying representation. 

For example, a common abstraction In mathematics Is the 
concept of a set which we might define by the operators 
union, membership-testing, and Intersection. To Implement 
the set abstraction, we choose some lower level 
representation for a set. Our choice of representation 
depends on the kind of operations which will predominate In 
the application expected. We could represent a set as an 
array or possibly as elements linked together by pointers. 
After choosing one of these underlying representations, we 
would program the operators given above. This would complete 
our Implementation of the set abstraction although It may he 
the case that further refinement with respect to the 
representation chosen and the operators deflnod Is necessary 
so that our program Is completely understandable hy the 
actual machine. 
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lt is also a fact that at a higher IrvpI wr need not nor 
should we have access to the lower level (underlying 
representation of some data ahstractlon. This restriction 
has hoen Implemented hy most higher level programming 

languages for primitive types and there is no reason that we 
should Ignore it while programming hy levels of ahstractlon. 
For Instance, a real number In a nrogramml ng language Is 
usually represented as a seauencc o' hits which gives the 
mantissa and exponent parts of the numher. However, there Is 
certainly no reason for the programmer to know wh Ich h I ts 
represent which part or even to allow the programmer access 
to any bit. Indeed, this lower level representation of real 
numbers Is no concern to the programmer using the higher 
level tool of a programming language. This argument applies 
In a similar fashion to our example of the set ahstractlon. 
We are Interested In declaring variables to represent sets 
and In accessing Information about these variables through 
the operators associated with the set abstraction. nut the 
data structure that was chosen to represent a set should be 
of no concern to us. 



In summary, a data abstraction defines an abstract data 
type as a set of operators. Furthermore, the user Is not 
Permitted to know how this type is represented In the 
abstraction; instead, on i y the specified operators can 
manipulate variables of this type. it l s these criteria 



-2U- 

around which thp language for structured programming, 
mentioned earlier. Is help* developed at M.I.T, 

When judging the chosen programming languages, we must 
do so In terms of these requirements. Can we represent 
abstract data concepts and at the same time adher to the 
accessibility restrictions? If the answer is yes, thpn with 
what ease can this he accomplished? Poes any syntactical 
format or semantic concept of the given language encourage 
the use of structured programming as th*» designer's tool or, 
on the other hand, cause any serious handicap while ustnp the 
technique of structured programming? 

Before leaving the topic of criteria for data 
abstractions, v/e should f ocus on ore more issue upon which 
discussion ought to be based during the examination of a 
language. Suppose that we have conceptually formulated the 
model for a given abstract data type; that is, we have 
decided upon the representation of thp typp and thp 
operations which can manipulate objects of that typo. Our 
next step is to program this data abstraction In our chosen 
programming language. We should be concerned about the task 
of conceptualization versus the task of programming the data 
abstraction. Was the abstraction much more difficult to 
program than its conceptualization leads us to believe? If 
the language does not meet this criterion of 
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"conceptuallzatlon ease Implying prop ramml ng simplicity" then 
the language must be regard as a rf I seppo Intent from this 
viewpoint . 

.Stack Abstraction 



ave 



Let us now examine a data abstraction example we h 
chosen to program In our languages. Wo will name It the 
"stack abstraction". 

The stack Is a linear ,1st In which Insertion, 
deletions, and accesses to values am made at one end of the 
list. The usages of stacks are many Including the 

Implementation of a polish-notation Interpreter, the 
supporting of recursion, and the designing of parsing 
algorithms (eg. for operator precedence grammars we might 
wish to use two stacks called the "operator" and "operand- 
stacks) . 

When describing the concept of an abstraction earlier, 
we noted that it can be separate* Into two parts: Da 
representation of the data object (In this case the stack), 
and 2)operatlons on the object. The underlying 

representation we have chosen for a stack will he an array to 
hold the stack elements and a pointer which points to the top 
filled location of the stack. Operations on a stack that we 
will consider are the following: l)"push"-addlng an element 
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to the top of the stack, 2)"pop"--d e 1et I nr, the top element 
from the stack, 3)"top_etement"--access In* the top element 
value from the stack, and U )"i n 1 1 lal Izat ton"— In 1 1 [all zlnp 
the bottom element of the stack. Thus the stack abstraction 
Is conceptually defined. 

Lfnear li st Abstraction 



A second example we will Innk at will he referred as a 
HnearJIst abstraction. We wish to model three distinctive 
types of linear lists: a stack, a aueue, and a deaueue (see 
Knuth(16)). At the top level of abstraction all linear lists 
can be represented as arrays of locations. \t a lower level 
this representation may ho further specified depending on 
what type of linear lists we are using. A stac* abstraction 
would add as part of Its underlying representation a pointer 
to the top of the stack and t ^ operations that we have 
outlined earlier. A queue abstraction mtrht add "front" and 
"rear" pointers to Its ropresentat Ion and Implement operation 
of "enter"--wh!ch would Insert an element in the rear of the 
queue, and "remove"--wh tch would delete an element from the 
front of the queue. A dequeue abstraction could add 
"leftmost" and "rightmost" pointers to Its representation and 
operators— call them "Insert" and "delete"--wh I ch make 
additions and subtractions to both ends of the list. Thus v/e 
have Introduced the notion of hi erarch I rat data types and It 
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is of Interest to us to examine* how our languages can 
represent this concept. 

We will analyze each chosen lanpuap.e with two poals In 
mind: l)we wish to see what can he learned from programming 

In each language while attempting to meet the specifications 
of structured programming, and 2)wc want to determine If the 

language can he used as a structured programming lanpuape. 
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PL/I 

The block structured language, PL/K17), was developed 
by IBM during the mid 1960 f s well before the concepts of 
structured programming as a design mechanism for constructing 
programs were explicitly Introduced by Dijkstra. PL/ 1 was 
designed to cover as wide a range of programming applications 
as possible. The designers consider one of its prime 
features to be the case with which modular programs are 
built, encouraged by the fact that a PL/ I program is composed 
of blocks of statements called procedure dnd begin blocks. 

It should also be mentioned that PL/ I is an extremely 
large language and it is inconceivable to this writer how 
anyone could be knowledgeable of the complete language. The 
designers of the language recognized this as a possible 
drawback that would discourage programmers from learning PL/I 
(and companies from adopting the language) and have made 
programmers aware of the fact that one needs to learn only a 
small subset of PL/I in order to wr I to most medium-difficult 
programs. (After all, this covers the bulk of written 
programs.) However, the language does contain such options 
as multi-tasking so that one is able to solve more-difficult 
problems using PL/ 1 . As I present some of the language 
constructs and the examples, I may also be unaware of some 
"simpler" technique (although it is my belief that due to the 
enormous size of PL/I this is not my fault). However, I am 
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also quite sure that any "missed" feature could not change 
the overall outcome of the language with regards to data 
abstractions of structured programming. 

One might argue that PL/1 was not developed with 
structured programming in mind and therefore it is unfair to 
evaluate PL/ I as a structured programming language. On the 
other hand, structured programming is Intended to be a desir.n 
method based upon refining levels of abstraction until they 
are expressed in terns of whichever language — may it be PL/I 
or any other—that the programmer is using. Thus it seems to 
be perfectly justified to examine PL/ I in these terms. 

Data Structurln? Facilitie s of PL/I 

We begin by describing some of the data structuring 
facilities of PL/ I ; however, it will be assumed that the 
reader Is somewhat familiar with the language or at least 
some block structured language (eg. ALGOL60). Therefore we 
will describe only those data facilities that we might come 
into contact with when using the process of structured 
programming to write programs in PL/1. 

We begin with variables and data attributes. Variables 
may be considered to be single elements, arrays, or 
structures. Associated with each variable is a symbolic name 
and a value that may change during the execution of the 
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pro&ram. The attributes of a variable consist of Its basic 
type and storage class. Basic types in PL/ I arc FIXED(*), 
FLOAT, CHARACTER, lilT, and POINTER; storage classes of a 
variable are STATIC, AUTOMATIC, BASED, and CONTROLLED. 

While basic types should be clear, an explanation of 
storage classes is warranted. The storage class attributes 
are used to specify the type of storage allocation to be used 
for a data variable. The default class is AUTOMATIC, which 
means that storage is allocated upon entering the block and 
is released (freed) upon exit from the block. The STATIC 
class, on the other hand, specifies that storage is to be 
allocated at load time and not released until program 
execution has been completed. BASED and CONTROLLED give the 
programmer two different ways of explicitly controlling the 
allocation and freeing of storage by using the ALLOCATE and 
FHEE statements. 

A number of other possibly useful data structuring 
facilities with respect to structured programming exist as 
part of the PL/ I language. These include block structuring 
techniques (signified by BEG IN... END and PROCEDURE ... END 
blocks) which partially allow us to think in terms of 
abstractions (associating an abstraction wl th a block) 



(*) 

Upper case letters will be used to signify keywords In PL/I. 
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especlally with regard to operators. A second construct is 
the data attribute LIKE. Its function is to copy the 
structuring, names, and attributes of structures. For 
instance, suppose we wanted to declare a variable, s, to be a 
set (see Chapter 3). Assuming "set" were declared as a 
structure variable, we might write "DECLARE s LIKE set;". 
The result would be that s has the same structure as the 
variable set. A third facility of PL/I which we will 
investigate is LNTRY points into a procedure. This feature 
not only allows one to enter a procedure at some designated 
point (other than at the beginning) but also permits us to 
specify parameters and return attributes. Thus we may be 
able to set up numerous "operator" ENTRY points within a 
given procedure, which as a whole might represent a data 
abstract ion . 

Stack Abstraction In n/J 

Three stack abstraction examples In PL/I will be 
presented. This number of examples is due to language 
restrictions in conjuntion with program requirements. A 
detailed analysis of each example will follow the 
presentation of all three examples. 

In PL/ I the stack abstraction outlined in the previous 
chapter might be programmed as shown in fig. U-l. For now, 
it is important that we understand how the procedure 
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create_stack works. Mote that upon entering create_stack, 
not only Is space allocated for the stack hut also the bottom 
element is Initialized. He should also be aware that this 
first example is capable of handling only one stack at a time 
in existence. The operators seem fairly straightforward 
although one should note that pop deletes the top element 
merely by decrementlnc top and does not return that element, 
while top_element performs the function of accessing the top 
element but not deleting it from the stack. 
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create_stack: PROCEDURE(n); 

DECLARE n FIXED BIMU5); /* stack size */ 

DECLARE stack(n) CHAR(l) CONTROLLED; 
DECLARE Lop FIXED BINC15) STATIC; 

/* topmost filled location */ 

ALLOCATE stack; 

stackCl) « 'I'; /* Initial both the bottom*/ 

top e 1; /* clement and the pointer*/ 

RETURN; /* to the stack */ 

push: CNTRY(a); /* Insert the value of a */ 

DECLARE a CMAIU1); 
top = top*l; 
stackCtop) ■ a; 
RETURN; 

pop: ENTRY; /* delete the top element */ 

top * top-1; 
RETURN; 

top_element: ENTRY RETURIiS(CHAR( 1 ) ) ; /* get top elem */ 
UETURNCstack(top)); 



END croate_stack; 



fic. U-l 
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before proceeding further, we should also note that 
representing a stack as a controlled array is not the only 
representation one night think of. Indeed, the argument to 
represent a stack as a list of chained elements is solid and, 
in fact, this stack description will be programmed in a later 
example (see fig. U-2 > - Our declaration for a stack might 
have been written as follows: 



DECLARE 1 stock BASED(p), /* p is as pointer */ 

1 next HTU, 

2 value CHAR(l); 

PIctorially our stock would have looked like: 



>l 














next j i 




~~*~ ' 








""^"-"■^ 


value 





So instead of allocating the whole' stack at once, upon each 
call of the operation push (pop), a single element Is 
allocated (freed). 



The big limitation of fig. U - 1 Is in trying to represent 
several different stacks at the same time. This problem of 
multiple stack usage can be solved by rewriting the stack 
example using the LIKE attribute. Before doing so, a further 
characteristic of LIKE should be revealed: to write "DECLARE 
a LIKE b;" requires that b be declared on the same or higher 
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block level (a global declaration) than a. Realizing this 
restriction, the example Is programmed as shown in fig. i*-2. 
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DECLARE x FIXED BIN(15); 

DECLARE 1 stack DASED(p), 

2 m FIXED BINQ5), /* global decl. for stack */ 
2 hody CHAR(m RLFER(x)), 
2 top FIXED BIMC15); 

stack_oj>s: PROCEDURE; 

/* Contained within are the following oper- */ 

/* ations : push, pod, and top__element plus */ 

/* the oper of initialize. The parameters */ 

/* stack_ref and clem refer to the stack in */ 

/* concern and hold the value of the element */ 

/* to which wc are referring respectively */ 

RETURN; /* no reason to call stack__ops */ 

push: ENTRY(stack_ref, elein); 

OECLARE stack_ref PTR, eten CHAR(l); 
DECLARE 1 name 0ASED( s tack_ref ) LIKE stack; 
name. top = name. top + 1; 
name. body (name. top) K clem; 

RETURN; 

pop: ENTRY(stack__ref); 

DECLARE stack_ref l J TR; 

DECLARE 1 name GASEDCs tack_ref ) LIKE stack; 

name. top ■ name. top - 1; 

RETURN; 

top_e lenient: 

ENTRY(stack_ref )RETUP.r!S(CHAR(l)}: 
DECLARE stack_ref PTR; 

DECLARE 1 name FJA3ELC stack_ref ) LIKE stack; 
RE TURN (name ,body(nane. top) ); 



i n i t i a 1 I z e 



ENTRY(stack_ref,eleni); 

DECLARE stack_ref PTR, clem CHAR(l); 

DECLARE 1 name BASED(stack_ref ) LIKE stack; 

name .body( 1 ) = clem; 

name . top a 1; 

RETURN; 



END stack_ops; 



U-2 
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ln conjuction with fl c , i»-2, at on outside block level 
(corresponding to a higher level of abstract ion— a 1 though no 
higher than the one on which the stack is declared), we can 
now write the following lines of code: 



DECLARE 1 operator BASEO(p) LIKE stack; 

/* operator stack */ 

DECLARE 1 operand DASED(p) LIKE stack; 

/* operand stack */ 



x » 100; 

ALLOCATE operator; /* the sizes of the bodies */ 

/* are now established for */ 



x * 10; 



ALLOCATE operand; /* the operator and operand */ 

/* stacks respectively */ 



CALL in 
CALL in 



CializeCp, 1 ! ' );/*lni tlal ize each stack*/ 
tializeCq.'S 1 ); 



IF. ..THEN CALL pushCp, 'a ' ); 

/* push 'a' onto the opertor */ 
LLSE CALL pop(q); 

/* or pop the operanJ stack */ 



top_clei'ientCq); /* y r,ets sot to the */ 
/* top element of the operand */ 



These statements in conjunction with the comments should be 
easily understood as to their meanings and results. 



teferrlnjs back to fig, U-l, wc recognize the fact that 
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tlils first program would work only for a single stack usage. 
On the other hand, this last example allowed usage for a 
multiple number of stacks; however because we have used LIKE, 
we have had to separate the representation of a stack from 
its operations. Suppose we did not want to break up the 
abstraction and yet would like to take care of the case when 
we had the need to use more than one stack. The resulting 
program might resemble that in fig. M-3. 



- i«o- 



stack: PROCEDURE; 

DECLARE 1 stack_element UASED(sep), /* struc. */ 

2 1ast__stack_e1ement PTR, 

2 value CHAiUl); 
DECLARE sop PTR; 
DECLARE wp PTR; 

i:et__stack_doscriptor ENTRY (CHAIU 32 ), PTR) 
RETURNS(PTR); 



DECLARE 
RETURN; 



create_stack: 

ENTRY(stack_namol, ini t); 

DECLARE stack_narnel CHARC52), inlt CHAR(l); 

DECLARE 1 stack_descriptor SASED(sp), 

'I 1ast_stack_descriptor PTR, 

2 name CIIAR02), 

2 top_pointer PTR; /* descr. stack */ 
DECLARE sp PTR; 

DECLARE stack_descrlptor_top PTR STATIC 

INITOJULL); 

wp *> ( ;ct_stack_descriptor(stacK_naniel / 

stack__descr iptor top); 
IF wp -- NULL THEN SIGNAL error; /* stack has 

never been previously created */ 
ALLOCATE stack_descr i ptor; 

sp->last_stack_descriptor=stack_descriptor_top; 
stack_descrlptor_top = sp; /* new top */ 

sp->nane ■ stock__namel; /* name of stack*/ 

ALLOCATE stack_el ernent; /* get first element */ 
sep->value = init; /* and set to inlt value */ 
sep-> 1 ast_stack_el ement = NULL; 

sp->top_pointer = sep; /* point to top of stk */ 
RETURN; 

push: Ef!TRY(ova1uc, s tacknamc2) ; 

DECLARE evaluc CHARC1), stackname2 CHAKC32); 
wp ■ get_stack_dcscr i ptor(stackname2, 

s tack_descr I ptor top); 
IF wp = MULL THEN SIUNAL error; /* not found */ 
ALLOCATE s tack_e lenient ; 
sop->valuc ° cvalue; 

sep-> las t_stack_c lenient 3 wp-> top_no I n ter; 
wp-> top_po i n ter ■ sep; 
RETURN; 



fig. U-3(paee 1) 
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pop: ENTRY(stack_name3); 

DECLARE stack_name3 CHAR<32); 

WP K Kct_stack_doscriptor(stacknamc3, 

stack_descr!ptor„top); 
IF wp = NULL Chen SIGNAL error; /* not found */ 
sep = wp->top__po Inter; 
wp->top_potnter ■ I ast_stack_e1ement; 
FREE stack_element; 
RETURN; 

top^element : 

ENTRYCstack_namel*)RETURNS(CHAR(l)); 
DECLARE stack_name<* CHAR(32); 
DECLARE top_value CHAR(l); 
wp = Ket_stack_descriptor(stack_r.amei*, 
Ir , s tack_descr I ptor top); 

IF wp * NULL THEN SIGNAL error; /* not found */ 
wp - wp->iop__pointer; /* indirection */ 

F wp - NULL THEN SIGNAL error; /* no element */ 
top_value = v/p->va1uc; 
RETURN (top.value); 

END stack; 
Get_stack_descr i ptor : 

PROCEDURE (ename,q)RETURNS<PTR); 

DECLARE ename CHARC32); 

DECLARE <q,mp) PTR; 

DECLARE not_founo GIT INITCl'B); 

nS u.i?fr , '* caU by ref trI <=ks avoided */ 

CO WHILE (not_found & rcp "*■ HULL); 

IF mp->name - cname THEN not„found ■ ' O'B; 

ELSE nip = mp->last_stack_descriptor; 

END; 

RETURN(up); 

END Get_stack_descriptor; 



t> ' 



*4-3(concl us ion ) 
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Ubviously, fl R . U-3 needs some explanation as to what is 
going on. The overall intent of the program Is to allow the 
creation and manipulations of more than one stack. This 
requirement is solved by construction a s tack_descr i ptor list 
whose function it is Is to keep track of both the stacks 
created and the elements of each stack. Suppose, for 
Instance, that outer program began with: 

CALL creatcstackC'operand', '$'); 
CALL create_stack( 'operator 1 , '!'); 

Then fig.U-U depicts the results of these calls. If the 

statements : 

CALL pusliC 'operand', 'a'); 
CALL push('operand r , 'b'); 

follow, the resulting modifications are Illustrated in fig. 
U-5. It should be fairly obvious to the reader that push, 
pop, and toi)_e lenient correctly perform thel r intended 
funct i ons . 
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s tack_doscr i ptor_top 
las t_stack_doscr Iptor 

name 
COp_po inter 

1 ast_s tack_ilescr Iptor 

nar.:e 
top <ioi n ter 



\ 



'operator ' 



las t_staek_e 1 oment 
val uc 




:iULL 

1 opera ik! ' 
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stack element 



flit, k-k 
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top_poi nter 



1 as t_stack_descr iptor 

name 
tOP_pol nter 



'operator ' 



;ULL 
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I ast_s tack_e 1 oment 
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ii! 
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IULL 



tack_e 1 omen t 



fig. U-5 



We should make a note at this time concerning our 
awareness of the fact that instead of naming stacks one might 
merely have pointers to stacks. The usage of pointers would 
certainly decrease the stack access time since we would 
Immediately have the location of the stack instead of having 
to go throuch the extra procedure get_stack_descr i ptor in 
order to find the stack. However, the stack would now be 
completely available to anyone programming* at some level 
higher than the stack abstraction. lie would not have to go 
through the operators to access the stack but merely use the 
pointer to the stack to chance and inforration about the 
stack. For reasons of preventing these accessibility 
properties, the naming of stacks has been chosen as the 
method for maintainence of a multiple number of stacks. 

Analysis nf pi,/| 

We are now at the stage of anal ysi s-- that is, we are 
ready to judge the merits of PL/ I with respect to the 
facilities it provides us for describing data abstractions. 
We will take each of the three examples (figures ij-1, h-2, 
i*-3) and present first the good points and then the bad based 
upon the structured programming criteria that must be met. 

Regarding the single stack example (fig. U-l), probably 
the most important point in PL/l's favor is the fact that the 
representation of the stack and the operators we introduced 
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are well-contained within the procedure create__stack. 
Furthermore the stack/ being CONTROLLED by the programmer, 
can be dynamically allocated and freed, thus allowing the 
designer a greater flexibility in determining the stack size. 
In addition, contrary to the usual hazards of flexibility, 
the requirement that the stack cannot be accessed from 
outside creatc_stack is satisfied. Programmer convenience is 
further increased by the variable attribute STATIC which 
designates that the last value of top is remembered upon 
reentering the procedure through create_stack or any one of 
several ENTRY points (corresponding to operators). And 
fortunately one is not permitted to access the variable top 
(thereby possibly changing its value) from outsitfe 
create_stack. Overall then, an air of safety surrounds the 
abstraction creo te_stack. 

How v/e present the defects of PL/I that this example 
illustrates. First of all stack is not really a data type as 
we would prefer but instead a variable. That is, we cannot 
say that x is a stack since stack is not a data attribute. 
In our example stack is not only the abstraction v/e wish to 
define but also the name of the variable. Obviously to 
extend this program to handle a multiple number of stacks, we 
must use more declarations. For example, \(e would be forced 
to write something like "DECLARE (stackl(nl), stack2(n2), 
stacl;3(n3)) CONTROLLED CHAR(l);" and simi lar ly "DECLARE 



Ctopl, top2, top3) FIXED BINU5) STATIC;" and finally rewrite 
the operations to make sure they will know on which stack 
they are operating. This really points out the fact that our 
operators have not been written to operate on the 
representation of some data type but Instead on the variable 
itself. Unfortunately because there is also no syntactic 
connection between stack! and topi, the housekeeplnc chores 
involved in Implementing the usage of more than one stack in 
this manner become sizeable while the concept of a stack and 
operators push, pop, and top_element are still simple. The 
question to consider at this stage Is, "Why should the 
implenentat icn of multiple stacks be so much more difficult 
than implementation of a single stack when the concept of 
more than one stack and associated operators has not become 
more compl lea ted?" 

Also rcnardlnr, the ENTRY statement, we see that one can 
simulate operation descriptions within a data abstraction. 
Mowvere, a couple of minor criticisms with rcj;ard to syntax 
should be brought to the attention of the reader. We must 

include each operator section with a RETURN s tatemen t--wh i ch 
has no syntactic connection with the operator--or else 
execution will continue with the next ENTRY statement. It 
might make more sense to write "END <ope ra t ion_name>; " (using 
UMF notation) to terminate each operation block. Secondly, 

implementation restrictions require us to declare procedures 



-47- 

and entry points at the level from which they are called 
(unless, of course, one wishes to try his luck with default 
conditions). This causes a syntactic confusion since the 
declaration takes the form PECLARE <nnm> ENTRY... . That 
Is. there Is really a second usage of the keyword ENTRY— a 
word which we depend on heavily. 

In defense of PI./ 1 , we must realize though that these 
last two points are basically Implementation and language 
design considerations that had to be dealt wlth-al though a 
more satisfactory way of handling these problems might have 
been Invented. However, the first criticism Involving the 
extension of example one to handle more than one stack and, 
In turn, rea 1 I z I ng that th I s extens Ion probl em I . caused hy 
the fact that stack Is not an abstract data type hut the name 
of a variable seems to be a very serious defect of the 
language. 

The necessity of a multiple number of stacks bring us to 
example two Cflg. U-2) which Introduced a usage of the LIKE 
attribute. Presented In this example Is the favorable 
impression that stack Is now a data type in the sense that we 
can declare other variables to take the same structure as a 
stack. As a result, there is no need to even confront the 
question of programming one stack as opposed to many stacks 
as had to considered In the previous PL/I example 
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However, »e must a, so exan.ne why the usa B e of LIKE , n 

tMs manner '-otas promlsinsasiti „ |tla|lyscems _ The 

deC ' am,0n ° f "^ «» — outside the stack ops 
Procedure in order to oe understood by dec.arat.ons of the 
for. -DECURE...LUE stack;" c... DECLARE operand BASE0(q) 
Ll« stack;). A -suit of this non-structured retirement 
I- that access to such e ,e men ts as operand.top is possible at 

PrOEramm '' n£ ' eVe,S " 0bal <° 'he stacks procedure 
(corresponding to higher -eve, s of abstract ion) . ln fact 
one can even ailocate storage for "stack" and manipuiate its 
Parts, say stack.top, a.though one would hope this not to be 
^e case; after all, stack is m ere, y supposed to play che 
-e of a data type and not a v a ri able wh ,ch can take Qn 
different vaiues. A part of the st ack structure we shouid 
examine is the variab.cm. It 

dyn^n.c oUocation of the body Part of the stack. Even 
though when considering the representation of a stack . wouId 
not come into focus, as it now stands . ,. as much . part Qf 
the stack structure as a re body and top. 

Suppose we ,ook a Uttle m ore carefully at the stack ops 
procedure. One soon rea , i zes that M I1. to the different 
operators rel y on the "overlay" Irnplen.entat ion of PL/! . For 
Instance if rewrite "CAUpushCu, -a');", push increments 
name. top (which is reaiiy operand.top) and assigns "a" to the 
top location of name (really operand. body (ope rand . top)) . 



This type of programming is both unclear and 

Implementation-dependent. Note also that En order to group 

the operator definitions, we designate then as ENTRY points 

withlnO the procedure stack.ops; however, we certainly hope 
that stack_ops, itself, will never be called. 

The last unfavorable point to be made here Is that, in 
general, one must refer to stocks by pointers rather than 
names (although the program could have been written using 
names— see fig. ^3— but this is more difficult). A side 
Issue to be discussed here Is the usage of pointers. 
Pointers are with respect to data as g^s are to control 
sequencing-unstructurcd(18). Perusing a program full of 
gotos generally means that at some point one will come to a 
line In the program and not be able to tell how one got there 
because that spaghetti -1 Ike sequencing structure of go tos 
that has led one to that line has long since been tangled and 
retangled in his mind. The same holds true for any extensive 
use of pointers. Once a piece of data has been accesssed, it 
is often the case that one is really not sure which series of 
pointers has been used to retrieve this piece of information. 
These problems of multiple access-paths means that attempts 
to prove these programs correct will fail almost from the 
start. 

It has already been noted that example three (fig. M-3) 
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has gotten around the extensive usage of pointers by 
accessing stacks by name in conjunction with the procedure 
get_stack_descriptor. Example three has certainly proven 
that it is possible to describe in PL/I the stock abstraction 
(its representation and operations) within a single procedure 
(called stack in this case). Also we may not access stacks 
directly from outside the procedure but must go through the 
stack operations in order to manipulate stacks. In general 
the ntessiness within the stack procedure is hidden from the 
higher level and thus this major requirement of structured 
programming concerning data and operator abstractions is 
satisfied. 

However, the process of designing the stack procedure of 
fig. U-3, while conceptually clear, produces a relatively 
unclear and unreadable program. Keeping track of both stack 
descriptors and stack elements is Indeed messy and confusing. 
Also due to our determination to use names Instead of 
pointers we have incurred an additional lower level procedure 
get_stack_descr I ptor which was not part of our original stock 
abstraction. The point to be made here is that overall the 
complexity of this solution in PL/I In no way reflects the 
simplicity of concepts involved in solving the problem. 

Suppose we now list the major favorable and unfavorable 
points of PL/I we found when attempting to use the language 



stack 
I y well 
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for structure! pror.ranmtin*;: 

E££L 
1) Sin G le stack abstraction consisting of tho 

Sr! i :f o Jhj h :«2?: b :KK.' no - us co d * fine — - ■• 

typls'cflj! '")! bUte "" be US6d C ° sinu,atfi abstra « ^ta 
(fi S y h S-3)? nera ' St ° Ck abStractlM ca " ti. pror.ron.ned in PL/I 

"pSssLS^^f °: s: efc Li s„ ^ r,i,u ^- ti,e «?*"'>"■. 

outside the stack abstractor,."" "' "^ lnacc «slbl e from 



1) One is unable to define stack as an abstract data type, 
be "aole' S'dli«,?" r,b " - '"f anS that tlle P«*r.wn.r win 

var Ia ab Je% SLttSS'K n ave s a JSuSSl'HlS JScTOffi'M 

(fig?%-2)"" e UKE Jttribute "«•"« extensive use of pointers 
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Me now C | ve a general critique resulting from our 
analysis of usi „ B PL/I in conjunction with the desl E n 

cramming. A quick glance at the 



Philosophy of structured pro 
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control features of PL/I shows that v/Ith a bit of fixing up 
it is perfectly reasonable to assume that the control 
requirements of structured programming can be adhered to. 
Tliis fix-up would involve adding the CASE statement* U) and 
eliminating all other control constructs except for 
concatenation (";"), I F-THEN-ELSE, and DO-WHILE. 

Furthermore, its block structuring facility is definitely an 
Improvement Cover, say, 1-ORTRAN 1 ) for describing control 
abstract ions. 

Certainly the strict top-down approach with respect to 
data of program development cannot be adhered to In PL/I and 
In fact the bottom-up approach is almost always taken. For 
example, to design the stack program wc would first build the 
stack procedure and test its operators; then the program 
would be further developed around the stack 

procedure — creating stacks, pushing on or popping off 
elements when required for the solution to the problem. 

With the ENTRY statement we can syntactically link 
operators to a c'ata structure, although certainly the 
designers of PL/ I did not intend for the ENTRY statement to 
be used in this manner. In the first place these operators 
would have been programmed as separate procedures while the 
ENTRY statement would be used to signify a secondary point 
within a procedure where the caller may wish to begin 
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execut ion. 



The failure of PL/I to provide the programmer with the 

ability to create abstract data types and make use of these 

in lower level declarations substantially Increases the 

difficulty of using PL/I in conjunction with structured 

programming. Certainly a haslc concept of structured 

programming is the representation of programs in terms of 

abstract data and operators. Abstract operators can be 

simulated by procedural mechanisms but one is left without 

any credible facility for representing aostract data types. 

Although one might argue that the LIKE attribute is a 

substitute for abstract type declarations, the fact is that 

nothing could be more untrue. The LI KR attribute deals with 

the creation of a similar structure to one already defined; 

an abstract type declaration corresponds to the creation of a 

nm data type (not necessarily a part of the language) and 

then the declaration of a variable whose range of assumed 

values and permissible operations are defined by that new 

type. The LIKE attribute hardly encourages the thought 

process of abstraction which is the basis of structured 
programml ng . 

For further analysis of PL/ I let us attempt to program 
the linear list problem outlined earlier in Chapter 3. Uc 
want to write a program the defines a linear list and, in 
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particular, stacks, queues, and dequeues. Each of these 
lists has a body associated with it and in fact the top level 
abstraction would simply consist of linear lists and the 
underlying representation of the body. At a lower level 
abstraction stacks, queues, and dequeues would be represented 
as refined linear lists together with particular operators 
associated with each type of list. 

Without thinking too long, one mlfiht try to program this 
in PL/1 as sketched In fig. U-6. However, after a bit of 
review one should realize that this program is nowhere near a 
solution to our problem. For one thing, there is only one 
body and therefore only one list. (To extend this to more 
than one body would he a somewhat complex problem that 
conceptually does not appear to be so difficult.) 
Furthermore wr can only access the stack, queue, or dequeue 
procedure from within the llnenr_llst procedure. This 

requirement is not necessarily a bad restriction; it just is 
not what we intended to design. However, if we chose to get 
around this problem by writing llnear_l!st, stack, queue, and 
dequeue as four separate procedures, we would be in 
disagreement with the results of our abstraction 
process--that the latter three are lower level abstractions 
of 1 inear lists. 
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Unear_1ist: PUOCEDURECm, n); 

DECLARE body(mtn) CHAR(l) CONTROLLED; 

• • ■ 
stack: PROCEDURE; 

DECLARE top FIXED; 

push: ENTRY 

pop: ENTRY' 

• • • 
END stack; 

queue: PROCEDURE; 

DECLARE (front, rear) FIXED; 

enter: ENTRY 
■ ■ • 
remove: ENTRY 

• * • 

END queue; 

dequeue: PROCEDURE; 

DECLARE (leftmost, rightmost) FIXED; 

• ■ • 
insert: ENTRY 

delete: ENTRY* 

END dequeue; 
EMU 1 lnear_l ist; 



fig. ti-6 
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One point that has not been previously mentioned is the 
possibility of "conflicting names". It seems perfectly 
reasonable that we might have named inti operations of queue 
In fig. U-6 to be push and pop — although they v/ould act 
differently that the push and pop operators of stack. (For 
Instance the roost recent element placed on a stack gets 
popped off (LIFO) while the element in the queue for the 
longest amount of time sets popped (FIFO).) So let us 
suppose that both the stack and queue procedures had ENTRY 
points named pop. Certainly at a higher level if we wanted 
to pop an element off a particular linear list, we would know 
which pop to refer to if we knew which type of list (a stack 
or a queue) we held, however, there is no way to do this in 
PL/I and In fact we would receive a naming conflict error 
message for having two ENTRY points (whether in the same 
procedure or not) designated by the same name. In all 
honesty, there arc at least two reasons why we should not 
expect FL/I to handle this in any different manner: Da stack 
or a queue is not really an abstract data type that can be 
designated as a variable attribute, and 2)PL/I does not have 
the facility to allow the programmer to design a data 
abstraction consisting of a representation and associated 
operation in a manner that means the language is now extended 
to include this new abstract data object. 
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Ovcr.'.H, it should be clear that using structured 
programming as a design tool lor writing programs in PL/I is 
nearly Impossible. When one sees papers titled something 
like "Structured Programming In PL/I" one can be sure that 
this paper simply addresses itself to the issue of control 
and / In particular leaving out the GOTO statement. This is 
a start but also close to the end regarding the extent that 
one can fol low the structured programmi ng approach to 
designing programs in f L/ I . (I have never seen the usage of 
the ENTRY statement included in papers of this sort.) Due to 
the restrictions of the language, PL/ I is far from being able 
to meet the criteria set forth by structured programming. 
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PASCAL 

Pasca1(19) was developed In 1969 by Niklaus Wirth. The 
design philosophy of the prosrainmlng language was based on 
two principal aims: first, to create "a language suitable to 
teach programming as a systematic discipline/' and second, to 
construct a language hnplomcntable as part of a reliable and 
efficient programming system. 

In reference to the latter of these two points, by early 
1973(20), Pascal hau been successfully Implemented on the CUC 
G000 and the ICL 1900. Furthermore, Implementations on the 
IBM 360, Sigma 6, CI I 10070, and PDP-10 are in progress at 
var i ous locat i ons . 



In order to evaluate the success of the first aim, we 
can refer to Iff rtli's recent bock Svstenacic P rop.rammi m- : M 
. lnCrodvjctip , a <21J which uses Pascal as its programmi ng 
language. In this book, Wirth is very much concerned with 
the explanation of systematic programming techniques, many of 
which are similar to concepts of structured programming. 
Wirth shows how programs designed in this fashion can be 
easily written in Pascal. 

When analyzing this language with respect to structured 
programming and, in particular, the representation of 
abstract data objects, we should consider the following 
point. Pascal is the only one of the four languages 
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prusented In this paper that was specifically designed around 
the concept of programme ng practices considered as a 
d i sc i pi ine. 

Uata Structuring Facilities of Pascal 

In Pascal data are described by dcclarat i ons and 
def ini t ions. Lach variable must be introduced by a variable 
declaration which associates a type and identifier with that 
variable. A da t^i type defines the set of values that the 
associated variable may assume. A data type may be directly 
described in the variable declaration or uy means of an 
explicit tvoc d ef ini t i on . 

It should be noted that Pascal is not a h lock-structured 
lansuar.e in the sense that its predecessor ALCOL60 was. 
Variables are declared either at the beginning of the 
program-- i n which case they are local to the whole program, 
or in a procedure-- i n which case they are local to that 
procedure . 

Uhile variable declarations in Pascal are similar to 
those of PL/ I , we should take a closer look at types and type 
definitions. Types are broken down into three categories: 
simple/ structured, and pointer types. 



The definition of a simple type indicates an ordered set 
of values. Simple types are divided into seal ar and subrange 
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typcs. The standard scalar types in Pascal arc I'oolean Ca). 

intcr.cr / Char/ and rxfll • Other possible examples of scalar 
types ore: 



(imimnal, reptile, bird, fish, amphibian) 
(subcompact, compact. Intermediate, full) 
(a, e, I , o, u ) 



Consider the following variable declaration: 

X2JL douon: (subcompact, compact, Intermediate, full) 

Thus "demon" can be assigned precisely any of four possible 
values — compact, subcompact, intermediate, and full. 
Suppose, however, that we wish to construct several "car" 
variables. We mlcht then construct the following type 
def in! t ion: 

car = (subcompact, compact. Intermediate, full) 

and then program the following code: 

var demon scar 

so that "demon" is now of type "car". The suhronce of a 
scalar type creates a new type defined by Indicating the 
lower and upper bound values in the subrange. Two examples 
of this arc (1..10) and (e..u). 



(*) 

Keywords in Pascal will be underlined. 
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Structured types In Pascal are character ized by 
associating a typo (or types) with components and Indicating 
a structuring method, of which there are four. The first of 
these is the array type which is comparable to PL/ I arrays 
except that Pascal arrays are restricted from being 
dynamically allocated. Examples of array types are: 

arrpy [1..100J of char 
arrQY [l..S,1..5| o_f integer 

The second structuring method to consider is called the 
record type. Each component of a record type is called a 
field and is designated by an identifier and its type. Tor 
example, letting "alfa" denote a character string type, we 
ml ght wr 1 te : 

record name :a I fa; 
ace: Ci.. 99; 

ssnum: integer 

So far this facility Is similar to PL/ I structures. Field 
access is accomplished by the dot <".") notation selection 
mechanism, also common to PL/ 1 . 

One added feature within the Pascal record types is that 
a tar. field denoted by the keyword case may he indicated as 
part of a record. This powerful facility allows one to 
specify several optional variants. The actual variant to be 
used will be determined by the value of the tar. field which 
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is specified by the programmer at or after the tinio the ty.ie 
i s ass i gned. 

For example, suppose Chat wo have defined "list" to be a 
scalar type such that "list s (stack, queue, dequeue)". Then 
the following record type could define a linear list. 

record body :ii_nxa_y_ [-100 . . ll)0] oj_ char ; 
case s : 1 i st oJl 

s tack: ( ton: i nterer ) ; 
queue :( rear : in ter.er ; 
front: integer); 
dequeue :( 1 of tmost : i ntccer : 
r I sh tmost : integer ) 

Then assunc at sor.ic later point in the program a variable x 
is declared to hove the above type. Then if "x.s", say, 
evaluates to the constant "queue", associated with that 
corresponding record type variable is a "body", "rear", and 
"front". (Since x represents a queue, expressions such as 
"x.top" and "x . 1 ef tmost" are conceptually inaccessible. The 
precise details concerning storage allocation for the 
variable and manipulation of "inaccessible" record fields are 
left up to the implementor . ) 

Set types are a third method of structuring. 
Characterized by the keywords set of . set types define the 
range of values as the powerset of the specified base type. 
(In fact, in the first version of Pascal, the keyword was 
powerset . ) If we write " set o_f.(rcd, yellow, blue)", then the 



possible values a variable of this type i.;oy ! jvc ar. : I I, 
1 red f, iyellowt, 1 b I ue f , I red, yellow}, Ired, bluel, {yellow, 
blue!, and i red, yellow, bluel. In addition, the operations 
union, intersection, set difference, and membership are 
defined for all set types. 

The file type, which is the fourth method of 
structuring, specifies a sequence of components all of the 
same type. Tor example. In order to construct the type 
character string we could write " f I le of char " ■ 

Finally, we mention pointer types of the Pascal 
language. Pointer types define an unboundeu set of values 
(comparable to memory addresses) pointing tu elements of the 
designated types. For instance, "t intoner " denotes that 
variables designated to be of this type may point to 
integers. Pointer types are commonly used in conjunction 
with the standard procedure nev; which generates a value of 
the specified type and returns a pointer to it. 

This completes our description of the data facilities 
available in Pascal. We now give some instances of type 
definitions just to make clear how one uses them. 
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Vowel B (a, e, i, o, u) 
List u (stack, queue/ dequeue) 
Hoard o array [l..8,l. .8] o_£ Boolean 
Text - file, ojl char . ._ 

Llnear_l ist*recpN bodv: arrav 1-1Q0. .lOOjoJL char : 
case s : L i s t of 

stack:(top: inter.er): 
queue: ( rear, front : intene r ); 
dequeue : ( 1 ef tmos t, 

r Ightmost : J n tcccr ) 

Before we proceed to understand the stack abstraction 
example given in the next section, we should examine the 
rules of parameter passing adopted by Pascal. Identifiers 

introduced in the procedure heading are called 

formal narai.-.eters. and the objects to be substituted for the 
formal parameters are called actual parameters . There exist 
four types of formal parameters in Pascal: Dvaluc 

parameters ("call by value"), in which case the actual 
parameter must evaluate to some expression and its value Is 
substituted into the formal parameter (the default case for 
Pascal), 2)variab1e parameters ("call by reference"). In 
which case the actual parameter must be a variable and Is 
substituted for the formal parameter, which must be preceeded 
by the symbol var , 3)procedure parameters, where the actual 
parameter must be a procedure identifier, an d U)funct ion 
parameters, where the actual parameter must be a function 
iden t I f ier . 

At this point in the chapter we are ready to read and 
understand the Pascal solution to the stack abstraction. 
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Stacl; Abstracti on, .in Pascal 

We would now like to construct a solution to the stack 
abstraction problem described in Chapter 3. Fin. 5-1 depicts 
a proposed solution to the problem wr I tten in Pascal. First 
of all we note that stack is a record type consisting of two 
fields: Da "body" which is an array of 100 characters, and 
2)a "top" of type integer. To declare variables of typo 
stack we would simply write at the beginning of the program: 

var s, 1 :stack 

Each of the four routines is simple. Three of 
them—push, pop, and i n i t i a I I ze--are written as procedures 
while top_e lenient is coded as a function. (Functions, as 
distinct from procedures ar^ characterized by labeling the 
type of variable to be returned—in this case char . ) In all 
four routines the char ond stack parameters (where 
applicable) are passed by value anc variable respectively. 
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stack - f.ftcorU bodvi arrav [l..l00] o_£ char ; 

top: intoy.Kr- 



prgcc -O .ur.o push (y:ejja_r_; var x:stack); 
b-ccin 

x, top :■ x. top + 1; 

11 x.top > 100 then error; 

x.bodyLx. topj := y 
end ; 

procedure pop ( var x:stack); 

if x.top < 1 then error; 
x. top : = x. top - I 
en<J; 

f unci; Ion top_element ( var x : stack) : ciiar : 

if x.top > 100 then error; 

if x.top < 1 then top_element : = 'e'; 

cIsp top_ e 1 ement :■ x . bodyLx . topJ 

ojlii; 

P.rocfcduro. initialize (y: char ; var x;stack); 
kejiia r - 1 

x.bodyLlJ := y; 

x.top :■ 1 



fig. 5-1 
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The structure selection mechanism says th.it if x is of 
type stock then "x.top" and "x.body" are its constituents. 
Of course "body" is an array type and so in general we would 
write "x.body [l] 1 ' for some integer i such that 0< i <101 . 

It should be obvious that these routines in conjunction 
with the stack type definition correctly solve the problem of 
programming the stack abstraction. We now proceed to analyze 
this example and Pascal in general, paying particular 
attention to its data mechanisms with respect to structured 
programming. 

Anal vsi s of Pascal 

Ue are now at the stage of analysis and ore planning to 
examine both the Pascal language and the stack abstraction 
example. This examination will be based on the criteria 
established by the btructured programming techniques. 

Describing first the favorable points of Pascal/ we must 
be impressed by the ease with which one can describe abstract 
data types using the different Pascal data facilities. This 
area of data types is such a central issue of the language 
that one is vr»ry much encouraged to think and program in 
terms of abstract data types. 

Just as the data type "stack" was easily expressed 
within Pascal/ so also were operations on a stack. Cach of 
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the four routines is short, correct, and easy to understand. 
Thus as the operations were conceptually simple to define, so 
also were they easy to code within the Pascal lancaunc. 

Another favorable point alonr, the lines of the stack 
abstraction program Is that obviously there are no 
difficulties incurred by attempting to use more than one 
stack (remember that multiple stack usar.e in PL/ 1 caused us 
problems). a declaration such as "xajl operator, 

operand:stack;" means that we have declared two variables, 
"operator" and "operand", both to be of type stack. 
Furthermore, stack functions are easily expressible, e.n. 

pop(oporator ) 
push(y, operand) 

Finally we must asain emphasize the outstanding quality 
that Pascal possesses: clarity and simplicity. This feature 
combined with the ability to express abstract data types must 
commit us to be favorably impressed with Pascal. 

However, Pascal does have some drawbacks concerning 
structured pror.rammi n C . Wo should be aware that a bottom-up 
approach is still required for writing programs. That is, we 
ore not able to code in terms of stacks and its associated 
operations before the stack type and operators are defined. 
This point is minor, however, since it could be corrected 
with the implementation of a library system which keeps track 
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of undefined objects. 

Pascal has a more serious fault that is well-illustrated 

by the stock abstraction example. Pascal provides no 
facility to syntactically link an abstract data type with its 
associated operators. In the example, the four routines are 
not defined as part of an encompassing stack type definition 
but are merely snail routines within some tarr.er program. It 
is furthermore unclear what happens if in a call to push, 
say, the second actual parameter is not of type stack--the 
type specified by the corresponding formal parameter. 
Perhaps some form of automatic conversion takes place. What 
we really want is for this call to r.ive the programmer an 
error. | n Uirth's book(21), he says that the "type of the 
actual parameter is determined by the type of the formal 
parameter, as specified in the procedure heading." This 
statement seems to imply that the type of the actual 
parameter need not be specified at the time of procedure 
Invocation which hardly makes sense and furthermore does not 
answer our question. 

A further criticism as a result of our inability to 
syntactically link a data type with its operators is that the 
lower level representation of ,» variable declared to be of 
that data type is accessible from anywhere in the program 
rather than only through the data type operations. For 
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Instance in our stack example, if "operand" wore declared to 
he of type stack then we could change the value of 
"operand. top" from any place in the program. (Jo ion C er can 
wc be sure that "ton" will only be incremented and 
decremented by routines "push" and "pop" respectively. We 
cannot even say that "top" is only set within the routine 
"initialize". Similarly, the "body" of any stack variable 
can be manipulated from any point within the procram. 

A related problem Is that of name duplication. We 
cannot have different operators with the sane name associated 
with different data types since there is no syntactic 
association of operations to types. 



's 



One final criticism of Pascal concerns the designer 
decision to disallow dynamic array allocation. The lack of 
this facility neans that a r.reat deal of flexibility is taken 
away from the procrammer. Icr example, in our stack example 
we may wish to have different size stacks, whose si.es are to 
bo determined at run time. however, this problem can not be 
solved within the Pascal lanp.uar.e. 

For the sake of reference, we list those major pro and 
con criticisms wo have made about Pascal. 
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1) The programmer has the ability to represent abstract data 
types and code routines which operate on variables of 
part i cul ar types . 

2) [Jo difficulties are incurred from multiple stack usage. 

3) Pascal is concise, simple, clear, and understandable — and 
yet a powerful langauge. 



Con 

1) Pascal provides no syntactic linkage mechanism to bind 
operators to their data type. 

2) Lower level representation of abstract data types are 
completely accessible throughout a Pascal program. 

3) Pascal does not provide dynamic array allocation. 

Overall Critique of Pascal 

The most striking observation one luakes when learning 
Pascal is the compactness of the language and yet the 
richness of the facilities for the construction of data 
types. Thus it seems that a language need not be so 
complicated in order to permit the process of abstraction in 
writing programs. This process is certainly the foundation 
of structured programming, and for that reason Pascal, looked 
at In terms of a structured programming language, must be 
regarded as a step in the rlp.Ut direction. 

The control structures of Pascal, which we have for the 
most part Ignored, are perfectly adequate for meeting 
structured programming requirements. However, it does seem 
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Odd that for oil of Wirth's intentions of introduc In- 
programming as an art, the ;:oto statement is a part of the 
1 anguage . 

Suppose that wo look at how one would code the linear 
list abstraction that was presented in Chapter 3. Pi;;. 5-2 
presents an outline of the program, ',.'e notice first that the 
££££. construct is both a powerful and useful feature of the 
Pascal language. It plays the najor role in discriminating 
among the lower level representation and, in turn, the 
appropriate operations. In terms of clarity and readability, 
the linear list Pascal program is certainly a success; 
however, we must be av.-are that the same structured 
programming criteria regarding data type and operator 
association and access restrictions are violated. 
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List = (stock, queue, dequeue) 

Lincar_J 1st = record body :a_Liay_ [-100 . .100] p_£ char : 

cose s:List of 

stack: (top: j_n.tef.er ): 
queue: (rear, front: inter.er ): 
dequeue: ( leftmost, ri f-htmost : tntoiior ) 

UT - "£Cdurg put_pn (vt char j y^n x : L inear_l i st ) ; 
case x.s ojl 

stack:|icr.'.U {pushf 

x.top := x.top+1; 
x. body[x. top] := y 
end ; 



queue: bewail (enter 

end: 
dequeue : bet, i n 



i nserc 



cnu put_on; 

funt ion take_off ( var x:Linear_1 ist) : c)ar ; 
-'>_cj; i n 

cjlic x.s ojl 

stack:L=cr.in ipopl 

x.top :■ x.top-1; 
takc_off := x .bodyLx . top+l] 
find; 

queue :kox_Lu I remove f 

iaid; 

dequeue : ber in j delete! 

end : 
end tal;e_off; 



fir,. 5-2 
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An Interesting paper wp must consider Is an article 
written by Habermann(22 ) which criticizes Pascal on several 
grounds. Habermann points out that one of Pascal's pitfalls 
concerns Its failure to Incorporate the ALCO160 block 
structuring technique, reminding us that "a sound programming 
principle Is to declare a variable at the placo where It Is 
used." One must agree with him on this point especially when 
looked at from the structured programming view. Block 
structuring seems to be a valuable technique when programming 
by levels of abstraction. 

With respect to data representation, the rain criticism 
of Pascal that Hahernann makes is Its failure to distinguish 
between types and structures. He makes the following 
definitions: l)a type defines a domain for the objects 
declared of that type and determines the operations that can 
be performed on thos^ objects, and 2)a structure defines a 
rule for connecting objects into larger units, hut operations 
are not on the structure hut arft expressed In terms of 
Individual elements of the structure. 

It is my belief that llabermann's complaint Is justified. 
Suppose that Pascal had actually provl^eH a means for 
constructing a stack abstraction that satisfied our criteria. 
Then from outside the abstraction, stac^ would he considered 
a type defined by certain operations (e.g. push, pop); 
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however, from within the definition of the stack abstraction, 
stack would bo a structure such that it Is composed- of a body 
and top, and the operations are coded in terms of these 

Individual components. The fact Is that Pascal falls to 
provide the programmer with the ability to construct the 
stack abstraction as a syntactic unit, thereby permitting 
stack to he viewed as both a type and * structure. In 
general, the language does not distinguish the use nf a data 
abstraction from its implementation. Without such a 

distinction, the confusion between types and structures is 

Inevl table. 

Overall, Pascal 'alls short of being a suitaMe tool for 
structured programming. We must concur though that If our 
earlier criticisms plus a top-down programming mechanism were 
Incorporated Into the language then Pascal would be Ideally 
suited for structured programming. Of course augmenting the 
language In this fashion Is an ambitious step forward, and 
the Pascal designers knew just how far to proceed without 
Incurring the major problems of designing a structured 
programming language. However, we must reiterate the point 
that this language was developed with the concept of 
systematic programming as its foundation, and from the 
results obtained It should be obvious that this specification 
Is a beneficial design criterion for any successful language 
devel opment . 



ELI 



The programming language ELI is the work of Cen Wesbrelt 
and was first described In his doctoral dissertation Studios 
itl E xtCnsiMr Umgu.jgy;s.(25) in June 1970. Although the 
philosophy of this language remains unchanged, a more recent 
description of ELI can be found in the ££L Programmer ' p 
ti^OuaJ_(2ii) written In September 1972. 

One can divide any extensible language into two parts: 
1) the core language defined by some set of syntactic and 
semantic rules, and 2) extension facilities permitting the 
programmer to design a more powerful language fro m the small 
core language. The core language of CL1 does not differ 
significantly from ALGOLG0 or, indeed, any other algor i thr.itc 
language. Following along the lines of any extensible 
language, ELI provides the programmer with a number of 
facilities for defining extensions so that the programmer can 
reshape the language to the problem at hand. These extension 
facilities exist in the following four areas: syntax, data 
types, operations, and control. Our investigation of LL1 
v/ill focus specifically in two of these areas: 1) data type 
extensions, which allow the programmer to define new data 
types and new information structures needed to model a 
particular problem, and 2) operator extensions, which permit 
the programmer to define new operations on new data types. 
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The following question must be answered. Using LL1, how 
easy Is it to construct data abstractions, each of which 
consists of a representation and operations defined on that 
representation, and yet adhere to the established criteria of 
structured programmi ng? tie fort! attempting to resolve this 
question, a description of the relevant data structuring 
facilities of ELI must be presented. 

Data Structuring Facilitie s uf ELI 

We now give a rather detailed yet informal explanation 
of ELl's data structuring facilities. This description will 
include treatment of variables, modes, mode-producing 
operators, datn generation, procedure and generic forms, and 
user-defined mode functions. 

We begin as in PL/ 1 with the description of variables. 
Associated with each variable is its name, mode, scope, and 
value. For example if we write "DECL one:INT liYVAL !;"(*) 
then we can make the following deductions: 1) the variable 
name is "one", 2) the mode of one is HIT, that is its value 
may take on any integer number, 5) its scope, although really 
relative to a program, is that block to which the declaration 
is internal, but excluding all contained blocks to which 
another explicit declaration of the same identifier is 



Upper case letters wi 11 be used to signify keywords In ELI. 
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internal, and U ) its initial value is 1 by the action "DYVAL 
1". 

There are seven primitive modes in ELI denoted by the 
mode-valued constants INT, REAL, LAUEL, tSOOL, CHAR, NONE, and 
UEF. While the meanings of the first five are fairly 
obvious, the semantics of the last two should be described. 
NOME means that no typo is associated and is the only means 
provided by LL1 for denoting that no variable is to be 
returned from a procedure. REF is equivalent to FTR in PL/ 1 ; 
that Is a variable of node REF is a pointer unrestricted as 
to the mode of en object to which it may point. 

Just as one can define variables of mode INT, thereby 
restrictinr, them to having INT values, so also can variables 
be declared to have mode MODE, to which only hODE values can 
bo assigned. for instance, suppose we write: 



ULCL truthvalue:MOUL; 
truthvalue <- 300L 



Then "truthvalue" is of mode MODE and its associated value is 
bOOL. Thus the result of some conditional part "truthvalue - 
UOOL" would evaluate to THUE. Furthermore, we are now able 
to use "truthvalue" as a data type in variable declarations, 
for example: 



DECL niiri tal_status: truthval 



ue 
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Thus "marltal.status" is a variable which can accept values 
TRUE or FALSE. 

However, the use of rOUE would be very uninteresting if 
all wc could do is use different variable names in place of 
our seven primitive nodes. We would like to have the ability 
to create new data types by operating in some fashion on 
those primitive modes we already have. In order to meet this 
objective, ELI provides the programmer with five 

mode-producinp. operators: SEQ, VECTOR, STPUCT, PTR, and 
ONEOF. These are discussed below. We will use ni, ml, 
m2,..,,nm to represent modes. 

1) SEQ(m): The type result of this application to in is the 

construction of a length-unresolved row of 
components, each of node m. For example, if we 
wr i te: 

DECL string:MQDE; 
String <- SLQ(CHAR) 

then the mode "strin;;" is defined as a row of any 
number of characters. The length of a variable 
declared to be of mode string must be resolved at 
the time of declaration. 

2) VECTORCi,m): For some lnte£er i, the new type defined is 

3 length-resolved row of i components each of mode 
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m, I f we wr i te : 



DECL int_array:MODE; 
!nt_arroy <- VECTORUOO, INT) 



then the "int_array" is constructed to be type "row 
of 100 integers". 



3) STRUCT ( name liml, 

name 2 :m2, 



nanentmn) : Given that namel, . . . / nanen are symbolic 
nanus 5/ the resultant mode Is the type structure 
consisting of n fields (components) whose 
respective modes mi may differ from one another. 
As an example, suppose we wish to Jefine a type 
named person as having a name/ a^e and sex. 
Assuming the existence of our earlier definition of 

strlnp,, the following statements would construct 

the des i red mode : 



DCCL person:MODE; 

person <- STRUCT (name : s tr in^ 

ai'.e : 1 TIT 
scx:600L) 



[*) PTROnl, . . . ,mn) : The result of this application is the 
mode pointer restricted to point to variables of 
mode ml or m2 or... or mn. For instance, if the 
type string were available tc us, we could write: 
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GECL strin&_ptr:HODE; 

string_ptr <- PTRfstrin/;) 

Then any variable of type strfn«_„tr may only point 
Co elements of type string. Note the difference 
between PTU and KEF: PTR operates on a node to 
produce a new data type and restricts the ranne of 
that type; RFF is itself a data type that Joes not 
make the above restriction. 

5) Or.'EOF(niI,...,mn): The result is the mode union of 

alternative modes ml ,nn where a variable of 

this type takes on a specific alternative based on 
its initial value. That is if we write: 

DLCL tckeiKfloriE; 

token <- Ch'EOFCCIIAR, INT) 

then any variable of type token can have types CHAR 
or INT associated with it. We should note that a 
orimary use of ONEOF is to describe acceptable 
types for formal parameters of procedures. 

Thus the use of these five operations permits the 
programmer to construct modes suited for his purposes. In 
contrast with PL/ I , this added flexibility provided by ELI 
will become a central issue during the analysis of this 
lanf;uai;e. 
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Wo now como to the area of creatine objects of any 
-wdo-a process which cones under the heading of data 
,oncratlon. r.Ll prov.des the progr aimer with two forms for 
generating data. The first is CONST wh Ich creates a new 
instance of some data class; the second is ALLOC which does 
the sane thing as CONST but then returns a pointer to that 
new Instance. For example, suppose we write: 

DECL st:sitr!n B DYVAL CONST (string SI2L 25) 

-ere st is declared to have type string (unresolved length 
mode). The object named by st has been created and given a 
l«"5th (as a result of "SIZE 25"). ifc cou.d also write: 

DTCL spl:string_ptr; 

spl <- ALLOC (string OF "Mark") 

In tilts case the right hand side of the second statement 
creates a new object of mode "string", Initializes that 
object to the literal string "Mark", and returns a pointer to 
the object; the assignment operation copies this pointer into 
sol. naturally the length has been automatically resolved to 
*. 

Procedures in LL1 are identified by the keyword EXPR 

(similar to PilOCtOURC In Pi / n ti,„ 

L "' "■/■)• Tim procedure naiiie is 

considered to have mode ROUTINE. t; e remark hcrt that EL1 , g 
on "expression-oriented" language, i.e. the final value 
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calculated within a block is considered to be the value of 
that block. The following procedure calculates the remainder 
when k is divided by j for integers j and k: 

Re.n<-EXPR<k:lfiT 13YVAL, j : I NT BYVAL-; I MT) (fe-(k/j )*j > ; 

Rem has parameters I; and j which are given specific values 
whenever Rem is called ( e ,«. r <- Rem(5,iO). Writing UYVAL 
implies that the "call by value" implementation will he used. 
The HIT following the ";" within the parameter list 
designates the type of value to be returned (namely the 
result of k-(k/j )*j ) . 

Proceeding we ml c ht use the Ren procedure in the 
following (inefficient) routine which determines whether or 
not a number is prime: 



Validprime <- EXPR (nui.iber : I iJT DYVAL; COOL) 
BEGIN 

PECL u:fcS00L BYVAL TRUE; 
uECL l:INT; 

FOR i FROK 2 TO (number/2 + 1) 
WHILE b - TRUE 00 
[) KemCnumber, i ) =0 -> 

b<-FALSE(]; 
I) 
END; 

Mote that L)...(] is equivalent to the PL/ I GEGHI...END 

construct and p -> q Is equivalent to the PL/ I statement IF p 

THEN q. The effect of the routine Validprime can be 
expressed as: 
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( TRUE If p Is prime 
Va 1 i dpr i mc( p) = \ 

{ FALSE otherwise 



where p is some integer. 

We mi the be concerned about what would happen if a REAL 
number were used as an argument for Validprime. Instead of 
trying to determine the "standard" tinfault mechanisms (which 
might prove insufficient for our purposes anyway), suppose we 
rewrite the routine, calling it Va 1 i dpr ime2, in which FALSE 
will be returned if number is AEAL or if it is not prime. 
This would be programmed as: 

Vfilidprlme2<-CXPr.(nupbcr:0NEUF< INT, REAL JBYVAL; BOOL) 

GENEIUC(nuniber) 

[HEAL] -> FALSE; 
[INT] «> 
DEGIII 

UECL b:300L BYVAL TRUE; 
DECL I: INT; 

FOR i FROM 2 TO 
(numher/2 + 1) 

WHILE b - TRUE 00 
[)Rcm(number, I )=0 
-> b<-FAL5E(J; 
b 
END; 
END; 

The OEriEll I C form of LL1 provides us an efficient means for 
choosing a particular execution pattern within the GENERIC 
body determined by the nodc(s) of the argumentts) of UENERIC 
(In Valldprime2 we examined the node of "number 11 ). Also the 
ELI form "p *> q" is read as "if p is TRUE then exit the 
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•""" -th . valu , q „. For reasons of conipnation 

efficiency, cad, statement within the GENERIC body nust bo of 
the form "p »> (| ", 

The last topic „ wlI1 cxamine , s ^ ^ ^ 
user-defi ned functions; we may best Qpproach jts cxpidnatfon 

■* ex,n l( „e. Sup p l)Sl! ,, havq def|ned ^ ^ ..^^ ^ 
the fol low in- W oy; 

DECL compTex;MODF; 
complex <« VECT0R<2, INT) 

Furthers suppose, after having defined son, variable k Co 
"a type complex, wo «l,h to occs tho first Integer In „ 
-l.«ch will represent the rea. part of the conpl.x vari a , )le x 
• »l«ht "rite -„(!,-, on the other Land, for the Sakeo f 
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readability, we nl C hc wish to write "x.re". 
the latter notation, we can dcfin. 



In order to use 
e a selection function for 
"complex" numbers which, in turn, w ,„ be colled by thc 
constructions xCi) and x.s where i is some inte,er and . ,. a 
«y«bol. The "coBploK selection" (con,) function would then 
bo written as follows: 

["IT] -> a Cm); 

[SYMBOL] «> [) m ="re M -> a(1); 
m="Im" ■> aC2)' 

END; CJ; 
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Howcver, upon closer Inspection one should realize that corns 
will not work satisfactorily. We said earlier that whenever 
v/e use the notation "x(i)" corns will be called. 
Unfortunately then, once corns is called, it will recurse 
forever since we ere returning one of values aim), ad), or 
a(2) — all of which will force calls back to the selection 
routine corns. 

We now analyze how the desicrter of CL1 has solved this 

problem of infinite recursion by introducing the operator 

:: . Instead of definlne "complex" as we aid, we should 
have def i ned it as : 



complex <- QL("complcx" / comc, coi.ia, corns, comp) 
::VECT0P.(2, INT) 



■ Jus says that the node complex has an underlying 
representation (UK) consisting of a VFCT0R(2, I NT) and 
associated with the name complex <iro the operations of 
conversion (come), assignment (coma), selection (cons), 
printing (comp), and generation (come). These operators are 
identified by position within the t)L (quoted 1 1st) — that is, 
QUI) ^ives the name of the mode, QLC2) identifies the 
conversion routine, and so on. These routines will be defined 
by the user (as v/e attempted to do for corns) and are to be 
invoked In place of any default mechanism when that 



Particular type of operation needs to be performed. For 
instance, the assienment routine would be invoked when a new 
value is assigned to on object of the particular mode for 
"hich the assienment routine was written. The awlnnnicnt 
routine can be called either explicitly by the " <- » 
operator or implicitly by the OF or UYVAL constructions 
within ALLOC or CCtlST. Si,,i lar rules exist for the other 
four operations. 



V c s 



We now introduce LIFT and LOWER as general prinit 
which pernlt the user to attribute different modes to the 
same object. tilth this ability, user-defined mode funtlons 
arc able to nanfpulatc objects of a r.iven node without 
recursively calling thonselves. 

Consider the Following example. Lot x be a particular 
complex number, say x = 9 + 71. In -LI, assuming that the 
assignment routine (coma) is previously defined, we can 
describe this by: 

DECL x: complex CONST (complex OF 9,7) 

Then we can talk about LOHER(x) which refers to the 
VECT0IK2, INT); specifically, LOl.'CIU x)[l] « u and LOHER(x) U ] 
* 7. Thus use of the LOWER facility elves us the ability to 
present a corrected version of cons: 
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coms <- EXPR(a:complex,m:ONEOF(INT, SYMBOL); INT) 
(itHER I C(m) 

[I'iT] «> LOWERCa)[m]; 

[SYMBOL] -> [) m ."re" -> LOWER(o)Cl]; 



m«"lm" *> LOUER(a}[2]; 



(]; 

Wo thereby not around the recursion problem and successfully 
define the selection rouiitlna for complex numbers. Note that 
coins will be colled whenever we write x(l), x<2), x.re, or 
x.lni. However, it would also be colled if we wrote x(3) or 
x.sq and so obviously "breakpoints" signifying errors In 
selection should be placed in appropriate sections of corns. 
As one would expect, the LIFT function has exactly the 
opposite effect rs the LOWER facility. 

Although this description of LL1 has been rather 
informal, it should rive the reader a f a i r 1 y good i dea of 
the concents around which the lanBuaiw was developed. In 
addition, one should hove Rained a .,orkin c knowledge of the 
relevant parts of ELI in order to understand the examples to 
be presented (next section) and to accurately examine the 
lanr.uar.e's usefulness with respect to structured prof.rammi „ B . 

S.tflCl; Abstraction. > r ri ) 

We now present the stack abstraction written in ELI. 
Obviously a „y example can be programmed in many different 



ways and, in fact, an F.LI procran could be written wnic 



ich i 
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completely analogous to Che Pascal solution to the stack 
abstraction we examined in the previous chapter. However, in 
analyzing this language or any other, we arc attempting to 
adhere to structured programming requirements and use the 
language's fullest capabilities to Jo so. Fro:i my readings 
and discussions with people involved in the design of ELI, it 
is clear that the ability to program by abstraction was one 
of the goals that this language design was intended to meet. 
Thus tlii 5 example will be written in a style such as the 
developers of the language would have programmed it. 

We begin by cons truct I ng "stack" as a user-defined mode 
func t ion : 



stack <- 'iLC'stack", stc, sta, sts, ,stg) 
: :STUoXT(top: MIT, body :SEQ(CiiAK) ) 



Thus "stack" will have an underlying representation of a 
structure consisting or fields "top", which will represent 
the topmost filled location of the stack, and "body", which 
will hold the elements of the stack. Note that the size of 
the body is unresolved and must, therefore, be resolved at 
the time of stack generation. Associated with a stack are 
operations of conversion (stc), assignment (sta), selection 
(sts), and generation (stg). (I have chosen to ignore the 
construction of a printing routine as it is not pertinent to 
this example.) These four operations will correspond to pop, 



push, top_element, and Initialize respectively. 

The first of these routines that we will examine is stc: 

stc <- 

CXPIUxrstack, f in t MODE; CHAR) 
BEGIN 

DECL f : INT UYVAL LOWER(x) . top; 
I1CCL temp:CHAR; 

fi.i -■ CHAR ■ > TYPE_FAULT(stack,fm); 
f-0 -> BREAKC'stack empty"); 
temp <- LOWLRCx).body(f); 
LOWtlUxJ.top <- f-l; 
te^ip 
END; 

The routine, stc, will be used as a popping routine. 
Suppose j and s are variables of types CHAR and stack 
respectively. Then if we write the conditional statement "s 
-> j", the conversion routine, stc, will be invoked since s 
is not of type COOL. All conversion routines take two 
arguments; the object to be converted and the desired mode 
of the converted result. Here the desired mode is the formal 
mode of the second parameter when it is equal to CHAR. (We 
should note here that the i nternal representat ion of al 1 
forms in ELI is LISP(25) and so stc would be colled by (-> s 
J) such that the •'->'■ is responsible for calling stc with 
Parameters s and J.) , ow stc takes over by creating 
temporaries f, assigned the value "top of s", and temp. In 
which the valu, of the block will be stored and returned. 
initially, two checks are made to make sure that j is type 
CHAR and s is not empty. If either of the outcomes is FALSE 
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then the correspond f nr. systen routine, cither TYPE_PAULT or 
CREAK, will be invoked. If both outcomes ore TRUu, we set 
temp, decrement the top of s, and return temp which ,>ets 
stored into j. Thus we have popped off the top clement of 
the stock s and placed it into the character variable j. Wo 
should make a note here that in the previous pop routine in 
PL/ I, we simply decremented the tup-of- the-s tack pointer but 
die nsil return a value. The reason for this difference is 
only a matter of personcl choice and independent of which 
lan^ua^e we use. 



We now 



present one! discuss the assignment routine: 



stn <- 



CXPR<x:stack, y:Cr!A!>; CHAR) 
BEGI1I 

UECL f:IHT EYVAL LOWER(x) . top; 

f <- LOWClUxKtop <- f + 1; 
f > LEHGTH(LOWERCx).boriy) 

=> BREAKC'stack overflow"); 
LCV/CfUx) .bodyCf ) <- y 
END; 



Let s and k he variables of modes stack and CHAR 
respectively. Then the assignment statement "s <- k" will 
have the effect of pushing the value of k onto the stack s. 
The internal representation (<- s k) will Initiate a call to 
the routine sta which, int turn, her.lns by declaring the 
Integer variable f and initializing its value to the top of 
the stack s. Then after incrementing top and f, a check is 
made to see whether or not the stack size of s, which con be 
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determined by use of the LENGTH function, has been exceeded. 
"f not, then the value of k is pushed onto s. 

Next we examine the selection routine: 



sts <- 



EXPR<x:stack, fd:SYMB0L; CHAR) 
GENERIC (J 

fd « "top" => BEG I n 

L0WER(x).top "*« -> 
LOWER(x).body 
CLUWER(x).top); 
BREAKC'stack empty") 

C nC 

fd) 



tun; 



T°.UE => GCICCTIOILFAULT (stack. 



If s and y arc variables of ^ dos stflck and char 

respective, y, then the assignment "y <- s.top", having the 

internal form «- y (. s top>)# cauS(?s thc inv<;cac , on Qf ^ 

in order to process (. s top) . , n sCs ,„ ^ advantacc (of 

compilation efficiency) of the CCNER.C for,,, with no argument. 

Which in this case has the effect of the PL/ I 

IF-ThO-ELSE... IF-THEN format. First, sts makes sure that we 

arc oniy selecting the "top" decent. If this is TRUE, then 

upon confirming that the stack is not empty sts returns the 

V,1,UC '" IO " tion <°" <>f stack s. namely 

"LOHER(x).body(LOWCR(x).top)». If we try to access any other 
element of the stack besides the "top" clement, the system 
routine GLUCTION.FAULT wI ,, beinvokod . Thus the ovcra 1 1 

effect of sts is the same as the top_element procedure in 
PL/ I . 
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We now take look at the final routine, the generation 
procedure : 



stg <- 

tXPlUbiBOOL, s: SYMBOL, 1 : FORM; 

OHEOFCstack, PTR(stack))) 
BEGIN 

b -> ALLOCCANY BYVAL stgtFALSE, s, l))s 
s = "SIZE" ■> 
LiEGIM 

DECL n:ll!T GYVAL EVALO.CAk); 
n LT => URCAKC'Cannot COIJST 

stack of negative size"); 
DECL r:stack.UR CONST(stock . UR 

SIZE n); 
r.body(l) <- "J"; 
r.top <- 1; 
LIFT Cr,staclO 
END 
BREAKC'CO'IST FAULT— stack CONST only 
by SIZE") 
END; 



Tins routine is explicitly called by the CONST and ALLOC 
forms. Suppose we write: "DECL s:stack CG'JSTCstack SIZE 
100)". Then the job of stg is to generate a stack consisting 
of the "top" rield and o "body" field of 100 CHAR locations 
and perform certain in 1 1 ial Izat inns associated with any 
stack. In greater detail/ upon reading CONST, sty gets 
called. The parameter b, which the system provides, 
specifics heap feneration If TRUL--in which case sir, returns 
a pointer to the stack object—and stack r-.cneration if 
FALSE--in which case the actual stack object is returned. 
Then stg i, lakes sure that we have used the SIZE generator (as 
opposed to the OF or 5YVAL possibilities which we have 
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^cidcd not to permit), I.ext, the temporary variable n is 
created and set to the value 100 CM. CAR"). (jiven thaC „ „ 
not l.u th.n 0, « dcclar. r ,„d construct it as the UR 
(underlying representation) of a stack h.vlns a body of 100 
CHAR locations and a ton. At this point the r.eneration 
Procedure initiates the bottom element of r and sets top 
OQual to 1. Final iy "LIFT (r, stack)" returns the value of r 
by SteLl^ with stack, thereby constructing s as we wanted. 

TI>o stack example is now complete with the possible- 
exception of a printing routine which was felt Irrelevant to 

tMS C ° nCeXt - ThUS « •"■«.« th« point of analysis, takin, 
both the stack abstraction example and the lan.ua.e Ell and 
examining then, as they relate to our structure,! pro C ran„n.n K 
criteria. 

Analysis gf ri i 

This section, which is concerned with the analysis of 
ELI, will l,e,,in hy describing the favorable features of the 
lan 8Ua « with respect to structured programming. (,„ sonp 
-nations, it win be easiest to refer back toona.ogous 
PL/I discussions to make explanations more clear.) 

For instance, when constructing the stack abstraction in 
ELI there was certainly no need to consider the problem in 
ten, ls of one stack or a multiple number of stacks as was the 
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case in PL/ 1 . The ability to r,o from concept to program was 
made easier to code in ELI as a result of being able to 
consider stack as a data type rather than a variable. So one 
of our basic cr i ter I a-- tha t of beinr, able to talk about 
abstract data types--is satisfied within the CL1 language. 

Continuing along the lines of data abstraction/ it 

should be noted that one of Wegbrett's r.oals during the 

design of ELI -./as to r.ive the programmer the ability to 

construct new operations on new data types. Furthermore with 

the usage of the "::" form one can actually restrict access 

of new operations to some particular data type. In our 

example, for instance, those four operations are restricted 

to variables of type stack. The fact is that we were able to 

syntactically represent our complete stack abstraction 

consistlnc of a stack represen ta t ion--STRUCT( top : I NT, 

body:SEQ(CHAU) )--and four opera tors--stc, sta, sts, 

5t£~"describlnc Pop, push, top_e1cment, and initialize 

routines respectively. Thus this structured programming 

criterion re&arciinn the representation of a data abstraction 

sccrns to be net by LLl--at least in this example. 

Another important area that must be ;;iven a favorable 
mark is that of recess restrictions. For instance, the 
selection routine (sts, in our case) can restrict what parts 
of a data type are accessible from outside the definition of 
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the data type abstraction. !!cforrin C to our stack 

abstraction as it now stands, r.ivcn that s is a variable of 
type stack at a higher level than the stack abstraction, we 
can ta.k about "s.top". However, if we try to access 
"s.body(i)" for some inter.or i, the sts routine will ,;ive us 
a SELECT I ON_FAULT error. Thus we can control the access of 
variables. 

The last favorable point we should review concerns the 
introduction and usa C o of the "::» operator. While the 
reader has already seen i ts has i c use, i t shou 1 d be noted 
that the "::" con be used for multiple level descriptions. 
For Instance, we mir.ht wr I U< "I 1st : :stOck: :...'■ where the 
underlying representation of a list is a stock and the 
underlying representation of a stack is the structure we f.ave 
previously. Thus the "string of pe a rls''U> description of 
structured progrpmnnng commonly used by oijkstra can be 
pro r ,ranr;ied in Ml lis in r the "::" form. 

We now proceed to examine tlie difficulties of usin C LL1 
in conjunction ,.-| th structured propmmnlnr techniques. The 
Hrst issue to discuss Is chat al thouch no can talk about 
abstract data types, we oust still prolan, in a bottom-up 
fashion. That is, we nust define "stack" as a mode-defined 
function before we can write "DECL ststack...". However, the 
designers of LL1 view this program,, in,, restriction as an 
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iuipl onentat ion decision rather than a result of the language 
descr i pt I on( 2C« ) . 

A more important argument against the use of E£ L 1 comes 
up during the examination of the stack abstraction we 
programmed earlier. One problem that always cane up was the 
necessity of having to use the LOWER operator to avoid the 
problem of infinite recursion. In defense of this language 
construct/ one might soy that LOWCR (or something like It) is 
necessary to solve the recursion problem; however/ this 
problem is a result of the language design in that the only 
way to operate on a stack is to use some variable of type 
stack as a parameter of the routines. The fact is that we 
need not operate on this parameter but rather on the 
representation of the given stack. What i-.e want is the 
ability to construct operations which operate on the 
representation of the abstract data type instead of 
constantly having to use the LOV.'tR (or LIFT) facility. 

A second issue to be taken up against LLl ! s method of 
defining a stack abstraction is one that is very obvious. 
What happens if there are more than five operations to be 
defined on some abstract data type? Cr just ;is critical is 
the fact that there i. light be some operation that cannot be 
expressed in terns of having to be Invoked by selection/ 
assignment/ conversion/ generation, or printing mechanisms. 



-09- 

Then all one can do is program those "excess 11 operations or 
that particular operation as standard routines not to be 
associated with the particular data type for which it was 
conceptually defined. This programming restriction, however, 
introduces many of the some violations of structured 
programming criteria that occurred in Pascal. 

The above defect, in itself, violates the structured 
programming criterion concerning the ability to associate any 
operation to a data typo. Hut let us consider the five 
routines that are ^art of the user-defined mode function, end 
in particular suppose we examine the stack abstraction 
example. The conversion routine, stc, was written as a 
Popping operator. First of all, this routine seems to 
violate the r.eneral meaning of conversion which normally 
means converting a value represented as one type to the 
corresponding volue represented as another type. Al thou G h 
the stc routine is i n i t i a 1 1 y invoked by the requirement for 
type conversion, the function of the routine is r.uch more 
than that. The fact is that the function of stc is not even 
related to type conversion. This type of programming can be 
exceedingly confusing and obscure, Next, we should note that 
a pro K ram which nokos use of the stack abstraction mi n ht use 
*'->" to mean pop and "<-" to mean push or top_clement 
depending on the types of variables on which the arrows (<- 
or ->) operate. On the other hand, the arrows may refer to 
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asslgnment and conditional expresions ropoctlvely. These 
ambiguities make for code which can ;*e difficult to 

understand. 

Now suppose we reexamine the issue of accessibility. It 
was explained earlier that from outside the stack abstraction 
for some stack variable s, s.body(i) was inaccessible. Vie 
noted however that s.top was accessible from anywhere in the 
program because the selection routine / s ts--programmed as 
part of the stack abstraction—defines the Meaning of s.top. 
Then if we assume that "." Is an operator particular to stack 
and invokes the operation / named sts, when s.top is written, 
then the program is expressed alori£ the lines of structured 
programming requirements. A conflict, however, is bound to 
arise here since if we had not defined sts, then by system 
default s.top would produce the value of the highest location 
filled in the stack; on the other hand, with the definition 
of sts, s.top produces t fie value in the stack of that topmost 
location. Thus depending on whether* or not "." is 

specifically user-defined for a given code the effect of the 
operator can produce completely different results. but we 
know that "." is a legal operation on any structure mode and 
therefore the programmer must be completely aware of which 
modes have user-defined selection routines and which respond 
to the default rout i ne--bo th invoked by the operator ".". 
The point to be made here is that if any of the five special 
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functions is not user-defined, then Che system provides a 
man Ins for these undefined functions; the program must be 
knowledgeable of which alternative Is taken in each of the 

roRram. 



Hve cases lor each mode used in the p 



To add further complexity to the above situation, a 
programmer ml B ht really decide that he wants to talk about 
"s.body(i)" fro,-, outside the stack abstraction. Ccnsieer the 
following style in which this program could be written: 

DECL sl:stack.UR CONST (s tack. UR SIZL 100); 

sl.boriy(i) <- "sonc character value"; 
si. ton <- some integer value"; 

The mode of si Is "stack.br." which is equivalent to 
"STRUCT<top:IKT,body:SEQCCHAR>>», ths underlying 

representation (UR) of the user-defined mode "stack". 

Thus although si is not really a stock, one night b 



Perfectly happy with this type of prosraimiln 
"W", the program reads as if si is type stack 



e 

C since by using 
oves 



differently. Tor instance, one can now wr i te "si. hody( I ) 



and access the value or assign a value to the ij^ locatl 
the body of si. ..owever, if sl , lad instead been doclare(J ^ 
have mode "stack" then the coding of "sl.body(i)" would have 
resulted in the invocation of the selection routine, sts, and 
-can a SELECT! DEFAULT error. So the programmer 



on i n 



can 
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seeminnly circumvent the access rules. 

However, the use of UR is not the only way that access 
restrictions can be avoided. Suppose that the variable s 
were declarer! to have mode stack, and let us examine another 
use of the LOWER facility. ELI allows us to program 
expressions such as "LOWER(s) . top" and "LOlLlK s ) .body( i )" for 
some integer variable I. Lach of these expressions invoke 
the system-defined routine for selection, signified by the 
dot ("."), instead of calling the usor-def mod routine/ sts. 
Thus use of the LOWER facility also permits the user to get 
around access restrictions. 

As a final criticism, let < ie remark that the routine 
definitions within an LL1 data abstraction can he confusing. 
For Instance/ suppose we look at stc in the stack 
abstraction. This routine was written as a popping procedure 
for some stack s rnd some character variable j. The fact is 
that if one were to write an instruction which pops the top 
element off s and places it into j, It would seem much more 
likely to use an assignment statement "j <- s" rather than a 
conditional statement "s -> j". The latter of these was used 
though to accomplish popping because conversion was required. 
It is not so simple as writing something like "pop(s,j)" if 
we wont to keep our stack abstraction intact; thus we must 
be complete 1 v aware of our data routines in that it may 
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actuaHybe a different (and possibly awkward) Cypp of 

statement that performs the intended function. If we are not 

extreme. y careful in this manner, trouh,e can resu.t that was 
not evident during our conceptualization of the problem. 

Finally, we list the major pro and con criticisms made 
of ELI In this section of analysis: 



'ro 



.ode-producinroper^torr 1 ""' tJ "»" ^ — «•• *" 

St.'t'ypi'brsiiSMs ws:.&:" ,om with * "■■"«"" 

pror,ram"" ih, cri^ IP rM Str ^n i0 ^ " ,0nB u thp fractured 

user-defined mode func'tions? * eStah " sh ^ within the 

-Con 
terms of the un^^ n ^« s ^ at ^ '^ ^/g^- '» 

assicnment, selection, D T nti °n, t Xne™ t i^"— s ' ""< 
wUh'J data S type? S5iMC C ° "»««'«« — than five operators 

can'be'can'dVuT^'in'c^^n c« I!" "V^'"" '"-tines 

in certain cases) completely obscured. 

roiIli« od ' s e^ ,e ^r y ,;s 1 ^. r 'hT" n " , or system - "•"-- 

understand. seemIn K ly a-blouous and difficult to 
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(v) Lxpressions which invoke user-defined routines may 
make code difficult to read and understand. 

3) established access restrictions can be avoided by use of 
both of the UK and LOWER facilities of CL1. 



Overall Cr itique of CL1 

In judging ELI with respect to structured programming, 
let us first give quick reference to its control structuring 
mechanisms. Obviously with its loop and routine facilities, 
ELI can adequately leau to well -structured programs when 
considering only control. The UOTO statement should be 
eliminated especially since the "=>" form cakes the place of 
any structured uses of the GOTO. Also the CEIiERIC form can 
be used to simulate the case statement and thus its use is 
approved by this writer* 

Mow with respect to data structuring, the first and most 
obvious point to be praised is ELl's facility which permits 
the creation of modes and definitions of operations on them. 
After all, that is a basic requirement of structured 
programming. However, for some reason, wo are limited to 
five of these operations when in general tin: programmer may 

need more. Of course we could define another procedure to 
operate on some mode but that routine will no more be 
associated with a particular abstract f.iode than, say, 
addition is with integers, e.g. we can also add real numbers 
and matrices ■ 
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Along those lines, Che point was brought up earlier that 
it might bo difficult to write an operation of some abstract 
mode in terms of one of the five standard calling 
routines — selection, assignment, conversion, printing, and 
generation. It is also a fact that it is not always clear 
when these routines are called, explicitly or implicitly as 
is sometimes the case. One has to be completely aware of how 
the language implements the usage of these special routines 
and, in fact, the internal representation of any language 
form and the knowledge of LISP are required to he part of 
this awareness, fly point here is that it is often the case 
that the programming of cne of these data type routines is 
seemingly more difficult to accomplish than it ought to be. 

Furthermore, one of the basic criteria of structured 
programming says that while the ability to use a data 
structure at sore programming level higher than its 
definition is guaranteed, one should not be aware of the 
lower level details of the structure. An obvious corollary 
to this requirement is that in no way at the higher level 
should the programmer be able to access any of these details 
of description. Unfortunately the UR (underlying 

representation) and LOUtR faci 1 itics, while useful In 

preventing the recursion problem Mentioned earl ier, 
contradict the obove criterion. For instance, one can 
discover the representation of stack by writing "stack. IR". 
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Ur if s were a variable of type stack, then one could write 
"LOWERCsKtop" and LOWER(s) -body" to avoid the selection 
routine, sts, and make assignments to the components of s. 

Another issue that should bo discussed is the view taken 
that one is able to represent a "string of pearls" using the 
"::" operator in ELI. Although this type of programmes is 
possible, the difficulty of simulating levels of abstraction 
is yet another problem. Suppose we take the example of 
llnear_l ist (given earlier in Charter 3) which could be 
refined as either stacks, queues, or dequeues — each of which 
would have a set of associated operotors. The problem Is how 
to represent the type linear_list. Obviously we would 
appreciate the ci i scr Imi nated union facility (see KoareCO); 
then the linear_Jist abstraction might be written as 
"1 lnear_l I st : : ( stack;qutue; dequeue)" which impl ies that a 
1Inear_list is either a stack, queue, or dequeue. From a 
structured programming view, this type of facility is one 
that ELI should incorporate into its language. 

Our overall f eel i ng about ELI is that it approaches 
acceptability with respect to the techniques encouraged by 
structured programming but does not go far enough in 
satisfying the necessary structuring requirements. The 
issues that have led us to this criticism of ELI have already 
been mentioned. However, before the discussion of CL1 Is 
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ended, one more question must be nosed. ;; w easy or 
difficult is (t to uaa the extension facilities provided by 
ELI? Because, if it becomes too awkward to use the extension 
mechanisms, the programmer simply will not attempt to use 
them. Instead he will Jo all his programming in the core 
language and most likely be successful in producing a 
finished product. Jowover, the final product will not be one 
resulting from the application of structured programming 
techniques; thus the issue of whether or not to use an 
extensible language in conjunction with structured 
programming is defeated before it can even be considered, fly 
experience was that the extension facilities of ELI were 
somewhat difficult to learn, and I believe that the above 
problem would exist for programmers using i-Ll, However, the 
language is fairly yoU ng and in a state of change, and so it 
is still my hope that this problem wl 1 1 be remedied. 

F,n ° ny ' ll is r.iy impression that the goal upon which 
the language was developed- that of being able to construct a 
data abstraction consisting of an abstract data type and 
operations which operate on variables of that typc--ls 
well-founded. The mistakes that the designers made were to 
limit the programmer in the way these operations could be 
constructed and permit too much flexibility in programming 
around a data abstraction and its imposed restrictions. 
Thus, although m 0: ,t of the structured programming criteria 
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can bo satisfied by the language, the above design errors 
mean that, in general, structured programming techniques need 
not be used to construct ELI programs. 



SIMULA67 

Developed in 1967, SIUULAC7C27) was designed as a 
ecneral purpose simulation lan C ua Se by Ole-Johan Dahl, Bjorn 
nyhrarr*. and Kris ton ,!y„ aard at tno ,; orweR|an Comp(Jt|ng 
Center. while SIJIULA67 includes most features of ALGOLuO as 
a subset, its automations are directed toward the area of 
simulation. The hope of the designers was that SIMULA67 
would be flexible and powerful enou,h to allow the programmer 
to orient the lon B ua,e towards specialised fields. To reach 
this noal, the concept of a EK rer,ates useful as building 
blocks for proRramnilnis was introduced. 

In deal ln 8 with lar~e problems with many details, 

decomposition is of prime importance. The fundamental 

mechanism for decomposition in ALGOL60 is the block concept. 

A block contains local variables and procedures; as far as 

these local quantities are concerned, a block | s completely 

independent from the rest of the pro. ran.. SIMULA67 was able 

to extend this notion by considering that the execution of a 

block wou.d result in a dynamic lpstor.cn of the block bein 6 

uenerotcd. Mock instances provide the capability for 

r.enerati,,;; sever,-,, instances of a r.iven Mock to,ethcr with 

its local variables and procedures. If we consider that a 

block could be used for defining a data abstraction, where 

its local variables and procedures are to represent the lower 

level description and operators respectively, then already we 
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arc aware of why SlltULAb7 might be successful os a structured 
pro/;ranuni ns I ancuaRe . 

We will examine how the above concepts of SIHULAG7 apply 
not necessarily to simulations as was orglnally intended/ but 
to structured pronromiutng and the ability to represent data 
abstractions. However, we first describe some of the 
important lanr.uaj*e constructs, 

[lata Faci 1 i ties of SIMULAfi? 

The new concept of SIMUIA67 in which wo are interested 
is the instance of a block which is called an oh jeet . Each 
object has its own local data and actions defined by a class 
dec! arat Ion. Our examination of class declarations will also 
include a description of obi ect none rat ion . 

The general Format of a class drclaration is as 
fol lows( *) : 

cl ass <main part> (**) 

where the <n.iin part> can be defined as: 



(*) 

Keywords in SIMULAG7 will be underlined. 



"<" and">" are i'.IJF net a symbols. 
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< id> ( parameters vl / . . . , vn>); 
<dedarat Ions for vl / ...vn>; 

bee in 

declarations for variables xl,...,xn>; 
<dcdaratIons for actions al,...,an>; 
<class body>; 

end < i d>; 



Then <id> in the above definition is the name of the class. 
The generation of any object belonging to class <id> will 

hove parameters vl, vn associated with that generation. 

The object's local attributes will consist of parameters 
vl,...,vn, variables xl,...,xn, and actions al,...,an. When 
the object is j.encrateri, the <class body> will be performed. 

To help clarify the proceeding definitions and 
explanations/ consider the Following example of a class 
declarat ion : 
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C lass square_matrt x(n); integer n: 
ber.in integer array T[l:n,l:n]; 
procedure transpose 

hep, in intcficr I /j/ temp; 
I := 2; 
J := 1; 
far. i to n do 

for j 1q 1-1 do 

ter.ip := T(l,j)j 
T(l,j) := T(j,|); 

T ( j , i ) t ■ t emp 

fiad; 

end transpose; 
h£Zin integer I, j; 
i := 1; j := 1; 
i&X. i StCP 1 untl 1 n sia. 

frcr.'n far. j step l unin n ^a 

T(i, J) : = 
£JUl; 

end square_matr I x; 



The above declaration defines the class of 

squarc_juatr i x . The associated data of each object of this 
class are the parameter n, which represents the size of a 
matrix object, «nd the local variable T, which holds the 
elements of the matrix. Also described is the local action 
transpose which operates on T. Following the action 
transpose, we have written a section of code which sets the 
array elements of T to 0. This section, which is the <class 
body>, is executed upon each object generation. 

Suppose that we want to Generate two square__matr I x 
objects — one of size 10 and the other of size 25. We would 
first declare two pointers to reference objects described by 
the class square_i intr 1 x : 
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ml(squorG_notrix);),b; 

CWo re M hcrc thot theseneral stfltement „ m (<c]ass . d>) 

<PCnter v a r.ab, es >« rea n y ,„ cans that chc <po|ntcr 

vanab.es> aro bound to an object denoted by the <c, as s ld> 
"any of its 5ubclasses (subcIasses „,„ be ^^ 

short, y), Generation of Che des , re d objects is coveted as 
f o 1 l ows : 



a :- new squar 



b :- 



e-nacr ix(lo); 



Q£H squaro_r : iatrix(25J; 



The built-in function n^ creates an object of the specified 
Cass (in this cose "scuare^atr , x «, and returns . refere nc e 



<° the object; the operator ":-" (read: "denotes") indicates 
the assi,;nn,nt „f . reference to a reference type variab.e. 
°ata belong to the object ,ay be referenced through use of 
the "dot notation" as the foilowin, expressions demonstrate: 

a.n 

I- • T C 1 ^ 2 ) 

o . transpose 

The notion of subclasses is the next construct of 



explore. Fir st oil we cxtcnd c „ e 



5IHULA07 we will 

definition of a Cass to include an optional < prc fix p art >. 
The syntax now becomt-s: 



< prefix u 



art) £_] a s^ <i:iain part>; 
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Semantical 1y wo neon that the class for which <preflx part> 
is the <id> contains the <ma i n part> as a subclass. Then the 
attribute list of an object corresponding to the <maln part> 
includes those attributes described in the <main part> as 
v/ell as those described in the definition of the <preftx 
part). The two parts are "concatenated" to form one compound 
object . 

Take, for example, the following class hierarchy 
consisting of six classes A, '.'., C, H, L, and P. 






s \ 



C 



r. 



Tl.is model is aescribed In SIMULAb? by the following class 
declarations: 



fi lass 
A class 




a class 
L class 
A class 


c. .; 
v . . . ; 
r . . . ; 



F. 



If we say that the corresponding lower case letter represents 
the attributes of the <tnain part) of an object belonging to 
that class, then the complete attribute list for each class 
is depicted in the following table: 
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attribute 1 


i St 


class 






A 


G 




B 


a, b 




C 


a, b, c 




n 


a, b, cl 




E 


a, t: 




F 


a, e, f 





It should be noted here that if we write "r_eJL(B)x" 
followed by "x :- new<D)" / the attribute list corresponding. 
to x (assuming that no attribute has been declared as 
Virtual —a concept to be explained later) will be a, b and 
not a, I,, d. This feet is a result of having hound x as a 
reference to objects of class B. 

A more concrete example of subclasses might prove 
useful. Suppose a pro* ram is required to handle real and 
Gaussian numbers. (Gaussian numbers are that subset of 
complex numbers where the real and inarinary parts are 
restricted to he integers.) While each type of number may 
have its own attributes, there are certain characteristics 
common to both types by virtue of the fact that they are 
numbers. In outline form, we might corle this pros ram os 

fol lows : 
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class number; 

bcfAn l nJ:_cft.er whole_part; 



.cr.il number; 

number c 1 a S3 real__no; 

bor.i n j_nj:ftr.c r riec_part; 



cn-i real_no; 

number cl ass r.auss i an_no; 

kffXla InUT.U'r im_pnrt; 



end caussl an_no; 

Then, for example, the reai_no 0.030 would be represented as 
havlnc a whole__part equal to G and the dec_nart equal to 030; 
the representation of the causslnn_.no 2 + Mi would consist of 
the v;hole_part and the in_part equal to 2 and k respectively. 

At this point it is useful to raise the question 
concerning the possibility of conflicting attribute names. 
This problem would result from defining two operations with 
the same nane--one defined in a class and one defined in a 
subclass of that class. Then the attribute list of a 
reference variable bound to the subclass would contain two 
operations wi th the same name. 

For instance, uslm.; the previous example, suppose that 
an action "add" were coded as part of the class number and 
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1 I kewi 



« another action "add" were proBraillmod w , th|n tho 
.«*•■«. S aussian_no. Thtn the guestj0n of tw ((ifferent 



add" actions cisso 



ciated with a eaussian 



- no object :.iust b. 



— Wed. T|1C semant[c ru , es of s|(!uu67 stipu]ate ^^ ^ 
■">.'*« class , f thll confnct ar , ses< thenon]y che mQst 

IOea " y fJef,ned «ctlo„ is associated 



Rofrrln s to „ ur exainple , chc , 



with that class. 



action defined in 
r.auss i anno is the nnl« ■■ -..1,111 

tne only acid operotlon In the attribute I 1st 

of caussian.no. Obviously this e„i„*. 

=»*y this bolut.on .s what we would 

hope to be the result. 



It should be mentioned, ho 



thi 



"ever, that the direction 



of 



"'^'^ ™" "» "v.r.0 -b,„,. flhe]tLuiaifaelll 



'" 5 «M"LA67. Consider the followln 
defined as a class 



« situation where A is 
ond C is defined as a subclass of A. 
SuPPCe also that „oth , and D contain definitions for an 
-rotion nanled •.,„,„,„. ^ ^ ^ ^ ^^ 

variable x as Vf(M x n T . n ., 

nx^lx . Then if we write » x :- newCfc)" 

followed by a reference to "x twiddle" . 

x. twiddle , we would be referring 

-the Cass AK However, if we define twiddle in A to he 

expression "x. twiddle" would occ 
definition for twiddle 

proeranimins approacl 



yrtMiil., the 

■-x.iw.B01e" would access the 

'»en by L. Thus, a top-down 
" can be partially used for writing a 
P««r« in SI „ULAG7. we say "partiaHy" because only 
—dure ,abe,s - swi tches (see AbCOUO > ,o y be bound as 
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vi r tua 1 quant i tics. 

Other features of SIMULA67 include the "r.roup access" 
feature. Suppose that m references a squarc_natr i x object 
and wc arc interested in examining the attributes of m. 
Usinr, the Inspect facility, we can write: 

inspect r.i slsi pg.ifn 



Manipulations of n and T, use 
of transpose, all these part 
of the object referenced by m. 



end 

which eliminates the need to use the dot notation for every 
attribute of a given object, however, it should be clear 
that the inspect feature is merely "syntactic sugaring" to 
the language. 

Another facility provided by SII1ULAG7 is instantaneous 
qualification. Por instance, suppose that we have written: 

fef (f:auSSJ on_no)x 

rcf (number )y 

Then "x iliiil number .wholejiart" and y ayi real_no.dec_part" 
are ler.al expressions for accessing the attributes whole_par£ 



a 



nd dcc_part respectively. Thus the <&& facility provides an 
increased flexibility for referencing attributes of 
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concatenatcd class objects. 

The ability to examine subclasses is also provided by 
SUIULAG7. This feature and use of the wj^ construct are 
displayed in the next example: 

££X( number )q; 

■ l i lSPc-ct u uiiiUl coinplex_no <lo_ ben in . . .pn_d 

Slilfia real_no do begin . . . , ;IU I 

otherwjpo. . . 

We have now been exposed to most of the data facility 
features present in SIMULAG7. So we are ready to discuss a 
SII1ULAG7 solution to the stack abstraction problem and 
analyze the 1 ancuaxt with respect to the structured 
programming view of data organization. 

Stack Abstract inn in S I : UJ I Ay7 

A solution to the stack abstraction problem, gjven In 

Chapter 3, is coded and presented in Fir;. 7-1. This 

representation of the class "stack" is fairly 

straightforward. An object Generated of this class consists 

of the following attributes: 

n—whlch represents the size of a stack; 

stack;^ ° rray ° f SlZC n Wh,Ch h ° ldS the ^ len,cnCs of the 

^r^! ' 1 |!°! ds , «*.'"*« of the topmost filled location in 
the body and .s initially set equal to zero; 
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pusli, pop, top_el cmen t, and 
perform the desired functions on 



n! 1 1 all zc- -ope rat tons whl ch 
objects of class stack. 



-121- 



Clasg stack(n); intopor n; 

kesill c.hgr. array body[l: n ]; 
■Intop.pr top; 

PrggfiMurr push(val); char vol; 
begin: 

Cop := top + 1; 

II. top > n .tli on error 

£_LS£ bodyLtop] 
iiad push; 



va 



'e 



L>rocr ( :L. rr |, op; 

fafigla; 

II top < 1 thofi error 

£li£ top := top - l; 
CILS1 Pop; 

ch flJl procoiiurr top_element; 

If. Cop > 100 then error; 

it top < 1 .then, Cop_e1cmenC . 

£±££. top_e lenient := bodyCtopj; 
filiii Cop_elcncnt; 

P . roc ? d»j^ initlaUzeCy); char y; 
be- in: 

top := 1; 

bodyLlJ := y; 

Qpd ini tlal kc; 

top := 0; 
£114 stack; 



fi>;. 7-1 
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A proftrain making use of this class mlsht begin as 
foil qws ; 



££_£( stack) operator, operand; 



operator :- new stack(lUO); 
operand :- new stack(75); 



Attributes of each stack intf.ht then be manipulated in the 
fol lowing styl s : 



operator. Inl t ial I *e( ' ! ' ) ; 



ope 



1± 



US 



and. pusliC T x ' ); 



per and. top > 100 . . . 



£££ operator do. imLLQ. 



op 



odyClu] 



end 
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Ue will now . 

some important 



our attention on 



-a m ino S.MUUG7 nuch 1W re closely and focus 



•ssues that have been 
M-.r.t* rrc th . solution t0 £he s£ack ^^^^ 

Analyse; rf sinui^ r,/ 

— j;;r;:r this — — 

" °- '" "" $ " ;U "" •'«'- «.l«lon ,o „, proMe „ 

- «• -.. .. w ta . iM ,„. ,. ,_ „ tii< „ : 

on tlv.s lower level representation. 

T ' le ab,,lt V ^ use parameter. 



as part of o class 



definition, such a 

■ 

type definition. 



was used In the stack 



olso proves useful. For i n , fa „,„ 

within r, ° Ur " Seof tte '"'«t.r n 

ll,th,n «» stock Cass Provided us with tho „•„ 

-.1. l " 1 " the nbilitv rn 
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Cont inui ng our presentation of the favorable features of 
SIMULA07, we note that this language also provides the 
programmer with the ability to partially program in a 
top-down fashion. First, the construction of subclasses 
encourages us to program in this style; second, the v i r.tual 
facility permits the programmer to refine a procedure which, 

in turn, can be invoked by r line of code which initially 

invoked the older, "original" procedure. 

One final point in favor of SU'ULA67 should he 
mentioned. Obviously there is no need to ^>e concerned about 
multiple stack problems Incurred during our use of PL/ I . 
Tills programming fortune is a result of being able to 
represent a "stack" as a data type (SIKULAG? calls it a 
class). Indeed, the simplicity with which the stack 
abstraction is expressed in SIHULA67 leaves the programmer 
with a favorable impression of the language. 

We now present borne problems one finds when using 
S1MULAG7 as a structured programming language. One of the 
ntost glaring faults occurs in the area of class definitions. 
Using our stack abstraction example/ we note that a stack can 
be syntactically represented by a class definition; however, 
some mathematical properties of stacks ore violated. For 
instance, consider the relation between "top" and "body" such 
that "top" always points to the first available location of 
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the "body". In our stack abstraction/ "body" and "top" can 
be accessed from outside the class definition, Dot only can 
these variables be manipulated by Invoking anyone of the four 
defined operations but also by simply writing such 
expressions as "operator . top" and "operand. body [i] " where 
operator and operand are references to stack objects and I is 
some integer. By allowing thp latter of these two methods 
for attribute access, we permit the above mathematical 
relation to be destroypd. 

Another issue which we commented on earlier (see Chapter 
U) Is the danger that can result from the extensive use of 
pointers. Unfortunately, SIHULA67 Hops not rive the 

programmer the choice of whether or not to use pointers. All 
objects must be pointed to by reference variables, thereby 

implying that oil object attributes are manipulated through 

the use of pointer variables. 

The usage of pointers seems to be the reason for the 
Implementation decision that a legal assignment between 
reference variables be carried out by "sharing". For 

example, consider variables x and y declared as references to 
the same class and x referring to sore class object generated 
by the function ££#. Then the assignment "y:-x" assigns to y 
a reference to thp object which Is the value of x. Thus any 
change made to an attribute of y results In a "side-effect" 
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on that attribute of x. Sharing can be useful; however, as 
the default mechanism for reference ass t pnments, the user 
must he on constant guard against s I de-cf frets . 

Finally the pointer Issue is further complicated hy the 
fact that the statement " ref (m)n" says. In fret, that n may 
reference any subclass of m. This unres tr I ct i ve feature In 
conjunction with the oua facility means that any attribute of 
a class or Its subclasses can be accessed, and furthermore 
that accessibility must proceed through a reference variable. 
Thus pointers arc just too much an integral part Of SIMUI.A67 
for us not to strongly object to this mechanism of the 
language with rrspect to structured progr.-"mi ng. 

We now list the Important pro and con criticisms we have 
made of SIMULA67. 

Pro 

1) The programmer possesses the ability to syntactically 
organize a data abstraction consisting of a lower level 
representation and operations operating on the 
reprcsentat Ion . 

2) Class parameters achieve a flexibility In generating 
objects. 

3) Subclasses permit the organization of programs into levels 
of abstraction, 

U ) The vl rtual facility In cnnjuotlon with the suhclass 
feature provides a partial top-down programming ability. 

5) The programming of the stack abstraction In Slf'ULA67 
corresponded In ease to the conceptualization of the solution 
to the problem. 
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Con 

1) i We can access attrthutes from outside their class 
def 1 n i t Ions . 

2) Class objects can be referred to only by pointers. 

3) The £fif and flua facilities complicate the pointer issue. 

Overall rr rltloue of Slf'UI A67 

It Is Interesting to note that SIMULA67 was developed 
before most of the concepts propounded hy Mjkstra on 
structured programming were well known; yet, this language 
captures one very Important program design techn i que— that of 
providing the programmer with a means for developing an 
abstraction which consists of a data representation and 
actions manipulating the representation. In particular, 
within the syntax o' the language, one develops a class 
consisting of attributes-- data and operations. 

Unfortunately, SlfHJLA67 still falls short as a 
structured programming language i n the following respect. 
Data attributes, which make up the lower level representation 
of an ahstract data type, are accessible from outside the 
class definition. Thus the programmer cnn manipulate these 
attributes when in fact ho should have no knowledge 
concerning the lower level representation of a data class. 
The point should be made, however, that due to the clean 
syntactic repmsentat Ion of a class, it seems th?t the above 
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fault could he corrected by signalling an error during 
compilation If one tries to access a data attribute from 
outside its respective class definition. 

The unfortunate deslr.n decision to access objects 
through pointers Is not so easily corrected. As was noted 
earlier during the discussion of PL/I (Chapter U), a pointer 
Is data's answer to the control's goto. Especially since re_f 
does not explicitly say to what o*^ject a variable may point. 
It becomes difficult at tines, for Instance during the usage 
of qua , to toll whore we cane from In accessing a given 
object. 

The vl rtual facility of SIMULA'S 7 and the usage of 
subclasses prove useful In programming top-down hy levels of 
abstraction. Concerning subclasses, fl*« 7-2 demonstrates 
the case by which we can code the linear list abstraction In 
SIMULA67. This program ^escribes stacks, queues, end 

dequeues all as linear lists with bodies but with different 
list markers (e.r. top, front) and different operations. 

Indeed, It seens that repardlng th** representation and 
organization of data abstractions, the designers of S1MULA67 
should he praised for their Insight. The languare provides 
us v/l th a good foundation for the development of a structured 
programmi ng 1 anguage. 
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dnss I ineor.J lst(n,u); inlsyr "/'•»/ 
i^p > 1 inear_l is t; 



linear_list class stack; 

bcr. in intOP.gr top; 

;>r rendu re push 



r. rococ urc nop 



cru! stack; 

1 inear_1 1st c1.if 3 queue; 

?Af,J.'. r - int^r.i:.r front, ruar; 
i-rocc-ilure enter 



>rfc?(iure remove 



linoar_l!st c 1 n s s vcqunuu; 

^r^jji in turn r leftmost, rightmost; 

,t r g c f n ' c* u r < : inserc 



nrocnviun? delete 



cm. i!e queue; 



fie 7-2 
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CONCLUSION 

The purpose of this thesis has been to study various 
pror.ror.iuinc languages for two reasons: Dto see what can be 
learned frow analyzing the use of these lan^ua&es in 
conjunction with a structured programming methodology; 2)to 
determine if it is necessary to develop a new langue&e for 
structured procrar.ii.il nr t . The success of these lancuar.es has 
been Measured in terns of t'-.clr ability to represent a data 
iilis t ract i on . 

Ideally, v/i: wonted a lan&ua; r .e to support a type 
abstraction riechanisni that would Include: Dthc ability to 
describe on eru'r-r 1 y i n.-; representation which would be unknown 
to a user of tiu t type; 2)a net hod by which operations could 
be defined within the abstraction. '.,'e also judged the 
lan-us;;es on how well .-; nronran represented the conceptual 
solution to tie problem at hand. 

- : " •''•dry 

Wc l.erjn this section by su-;r:;ar i z In.e, our findings for 
each lanr.aur.c. i'L/l was the first lanr.ua;, e wn analyzed. 
PL/t # while J<»scrih>:.! as <-;n all-purpose lanr.ua^c, linftod the 
user's ability to construct data abstractions. The stac!; 
abstraction had to be pro;; rammed as a procedure consisting of 
declarations and entry poin ts--corrcspond in:, tc a lower level 
representation and operations. ;\ general solution to the 
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stack abstraction (I.e. one able to handle a multiple, number 
of stacks) became a complex propran that was difficult both 
to write and to understand. 

For all of its power, then, PL/I cannot be used as a 
structured programming 1 ariRUPge-- I ts most basic fault helns 
that of restricting the programmer to certain data types. An 
attempt to circumvent this limitation rosults in a program 
that does not reflect the conceptual simplicity of a proMem 
sol ut Ion. 

The language Pascal was relatively simple to understand 
and use; furthermore, it provided us wi th the ability to 
construct data types. However, this construction was 
basically syntactic and not semantic because we could only 
describe a data abstraction in terms of a representation. 
The operations were defined separately from the type 
def i n 1 1 Ion . 

Hue to this restriction, our stack abstraction could 
only be programmed as a definition of the d.ita type stack 
followed by procedure definitions wMch operate on a stack. 
Unfortunately the result could not be considered a 
well-defined stack abstraction since the definition was not 
closed. The representation o^ the stack was totally 

accessible from anywhere In the program and thus, operations 
which manipulate the underlyinp ropresentat Ion of stacks 
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could be added Ly gny user . 

Pascal is nn improvement over Pi/ 1 in that it .Hows the 
construction of data types. ,t is necessary t0 conclude, 
-over, that PMe „ js inappropr|atc as q ^^^^^ 

programming lannua/:e. 

ELI was a P0 ,, erflJl a „ d conp]ex |af]guare chat introducc[| 
«»era, useful concepts. , t certainly perin| tted u$ t(j 
construct data types and analyze these types ,i th the GENERIC 

'«lllty. The "::■■ OB . rat0 |cnuse(1 , n conjunct!on „,„, fl 

data type definition, a11owcd , or t| , e con6truct , on of fl data 



Abstraction consisting of that definition and opcratt 
"hich manipulate the representation of that definition. 



pcration s 



Usin, these features, , e here able tQ consCruct fl 
Pronran, solution to the stack abstraction. The unfortunate 
Probl- was that the operations which manipulated stacks had 
to be written in terns of certain syste, routines ,..,. 
conversion, selection). Lacl , operation would then bo invoked 
'" Pl«e of the correspond I n E sys ten-do f ined routine. This 
.»ro,r i , l: „„„ R restriction ™dc the prolan difficult both to 



construct and to understand. 



"u also noted that by us in,; the 
■.vsterlous LCH.Tr: future, the lower ,evel representation of a 
Stock variable was accessible fro. outside the stack 
abstraction def ini t ion. 
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The ability to construct data abstractions in lLI is an 
issue that was considered by the lLI designers. Tills fact is 
evidenced by their introduction of the "::" operator. 
However, the restriction recardinr, operations imposed on the 
user when constructing a data abstraction makes it difficult/ 
if nut Impossible (i.e. when 'tore than five operations 
exists), to desij-n a rJven abstraction. r_LI in its present 
stone cannot be considered a lan(.'ua^e well-suited for 
structured proBrdrr.il nr; however, a serious study should he 
nade to investigate how certain changes to 1L1 could i".ake it 
appropriate for structured programming. 

SIMULA67 provided us with class definitions whereby 
objects of a ;-iven class could be created and referenced. 
Associated with each object were certain attributes defined 
by the class to which the object belonged. These attributes 
could be viewed in terns of a lower level representation of 

the object and operations which could r:onipulate the 

rcpresuntat i on. 

A program solving the stack abstraction problem was 
constructed in c straightforward way and reflected the 
conceptual solution to the problem. Stack objects could then 
be generated and referenced. Unfortunately, we found that 
the representation of stack objects was accessible from 
uutside the class definition. 
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The concept of cIass dpf|nItIons rprCfllnly soems 
-n.Kttou. to the MMttm nf ^ aKstract , ons _ |t |s 
Interest,,,, to not,, thouith# that thp ^.^ Qf ^^ 

th,t " W - ■ *"■ -"..rpcelon. The h „ le , |ffprpncp , s 
«■« * Cass , s vIfiwPd as „„,„ dpfInpd hy lts attrihutp 

'»«. Thl.1,., Infitudes Daranipt(?r n _ s> sinpiR yari?bip 
"— .. .nd Procedure M„,tlf|„r.. » d . t- ahstr , lctIon , on thp 
other hanH, „ tw>t „ f ? s oons-st-n, of a Wr ,eve, 
-Present.t.on .„„ on „ ratinns ^ ^^ ^ 

representation. 

™* S,niL W Wew of the e ,„. H flf ,n,t, n „ the cause 
^ our oKJect.cn to S.MULM7 as a structure oro , r?mn , Inr 
'•"«««.. One „ tl1(W to reference ?ny ohJe ct attr.hute- 
-not on,, , s on. p orp , IttPf) to ,„„.,.. , 
o-rat-on, ""ton, , saIsoaIloW(Htoacrpssnnypartofthe 

'«",.„, -.eMpMon of «,- oK,„t. The ,„„„ vloIfltPS 
"no of our structure* prorrammtnr criteria. 

ConoluHfnp Poi-. flr i.o_ 

Suppose that WP eon „ rf „ the foHow.n, qU est,on: ,f 
on-y operator attr,K„tes we r. naHe „„„„„,. 0( , tsMp ^ 
"«» ,ef,n,t,on. wW , IHJlA „ hp ,„,,„,.,. ^ ^ ^^^ 

Pn, ' r -" ,n « '~^ nur h .,Uf „ that th, s r.str.ctron 
«"" - - ...p.. chflnpp t0 tpp .^^ ^^ ^^ ^ 
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answer were yes, then SWUI.AR7 woufrf nullify as a structured 
programming 1 anpuape . 



Morrls(2o) provides us with some Insist Into answering 
this question. One of the most serious difficulties which 
arises Involves hlnary operations, for instance "eoual". 
ConsMer the proMen o' determining whether or not two stacks 
are oaual. Ue would like to dp £ ino 'Vnual" as an operator 
within the class definition for stack rlvr>n to f i".. 7-1. 
Without paylnp attention to thp ahove access restrlrtlon, the 
program outlined Tn fir, 8-1 would solve the nrohlepi. 
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Cl ftSg stark(n); [ntpiror n; 
hep. I n Intoggr ton; 

char array ^nrly[l:n]; 
procedure nush 

t ■ • 
proce^urf* nop 

• * * 

char procMuro t^D_r>l pmont 

• • • 

Ro Plfifln procprlurr ocual(x); reftstprM X ; 
hog 1 n 

11 tnp ^ x.tnp thop Poual : = f a 1 so 
el so r-p;: in 

P-oolnnn o o ; Intrror ] ; 

1 := 1; 

*h 1 1 p Uton * po Hn 

heel n ~ 

»q := (HnHyLi] = x.ho^y[f]); 
i :«= 1 + 1 



PIT* 

eoual :« eq 



end stack; 



*ir. 8-1 
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if s and t arr* defined as strict ohioct references, then 
the expression "s • actual (t )" Invokes "ectufll". The operator 
"equal", In turn, returns the Roolean value true If the 
stacks are equal and f a1 so otherwise. I'nw consMer any 
solution to the "eoual" operator which does not violate the 
above access restriction. In contrast to t^e solution just 
presented, wo pre. not allowed to use any expressions 
Involving "x.too" and "x.hody[l] within the procedure 
"equal". Instead o e writing "x.top", wp could construct an 
operator named "size" suc^ that when we write "x.slze", the 
value c* "x.top" Is returned. In order to replace 
"x.bodyCl]", wr m|e.ht hulld ,-m operator, calling It "copy"; 
then the statement "y := x.eepy" would Invoke "cony" which. 
In turn, would copy the "hody" or x into the array variahle 
"y". We could then proceed to analyze "y". It should So 
noted that the "ropy" operator would also take advantage of 
the "size" operator. This method of solution, however, 
Involves maklnr chances to our original definition of the 
stack abstraction merely to facilitate tho construction of 
"equal". The r^sultlnr prOKriuw Is also unsatisfactory 
hecause It Is hot^ nore comnllcated and less efficient than 
the original oronram riven In flir. 8-1. 

Suppose that we relax our restriction Hy saylnp that 
from within a particular class, one can access all attributes 
corresponding to any object o* that class. Tbrn, using our 
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Previous fixan , D , e , wh| , p „ ^ ^ ^ ^ ^ ^ 

t.t-P'-t.,K.th. B t.c k cU.., [t ,, OU H hp B _ pt8ble Co 
-»f "-.too- , w ,, tMn . o f , 0llrsp , thIs fpaturp wouid 

'-'» ^--r «M^ t , tI ^ th , (wiw 

«se. FvPn so , rt SBpms th3f wo ^ [m?(finp prnhjoms ^ 

compensate for the nart r=i , 

"e oartfal access restriction. 

Th ° P ° int " "' "•"■»'«- '• thn, w.tn «, ?CCPSS 

6 T " UMry — -Wt.cn. which are bIn . ry 
<««ch.. WI-, h.ro- d,f„cu.t. M n , t Inpossih , e/ to 

nnnrile them. 

Anothor pr „ Mpm Pncounterp<1 [n ^^ ^ 
-Mow.n,: «, „,,„, w(5 „ ^ _ an ^ 

™ that,s - ss •-— «- — - - class 

: th, v tsc,?ss " f,nmnn '-« — *-.».«, «, 

;;;; s - whMe thR - ■• • — - „, Pr to . Wo ,, w 

-son t0 PPrmlt , Vrrnr „ f _ ^ ^^^ ^^ 



Cass. We Snnu1 H hp ahle tQ SDprIfy ,„,, 



is hefn^ 
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external or Internal to an abstraction. 

Thus SIMULA67, nven with the flH^H restriction o' 
limiting outside access to operators, is not flexible enouph 
to be completely suitable as a structured programming 
lanfluape. While S1MUI.167 m*v be a start In the rip.bt 
direction, a new lan*ii*Ke needs to bo developed for 
structured n roe earning , 

However, this lanruare should Incorporate what we have 
learned from attempting to use these current 

1ane.uap:os--ospoo1ally SIMULA67. Obviously, the ability to 
describe a data abstraction nust he a central concern of the 
lan^ua^e design. furthermore, operations declared within a 
data abstraction should be describe *s routines which 
manipulate the underlylne representation o* the typo belnr 
defined. (In contrast to S1tM'lA67, "enual" would ho 

constructed ustne two parameters corresponding to the 
underlying roprosentet I ons e' starts s and t.) M so within a 
type abstraction, one rust b P *hlo to specify whether or not 
a given operation can ho Invoked from outside the 
abstraction. A laneunre designed around such features Is 
necessary for use In conjunction with structured prorrarml nr.. 
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